From bugzilla-daemon at llvm.org  Mon Nov  1 00:35:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 00:35:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7459] [MC] llvm-mc movsx/movzx not recognized
In-Reply-To: <bug-7459-206@http.llvm.org/bugs/>
References: <bug-7459-206@http.llvm.org/bugs/>
Message-ID: <20101101053534.E8F042A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-11-01 00:35:34 CDT ---
This is implemented in a long series of patches leading up to r r117901.  The
memory forms are not accepted when the size of the memory can't be determined.

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

From bugzilla-daemon at llvm.org  Mon Nov  1 02:22:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 02:22:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8519] New: Field offset not at char boundary!
Message-ID: <bug-8519-206@http.llvm.org/bugs/>

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

           Summary: Field offset not at char boundary!
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: wendling at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This is from a self-compilation with clang r117907:


$ /Users/void/llvm/llvm-opt.obj/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 \
-emit-obj -mrelax-all -disable-free -main-file-name FrontendAction.cpp
-pic-level 1 -mdisable-fp-elim \
-relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 97.14 -g \
-resource-dir
/Users/void/llvm/llvm-opt.obj/Release+Asserts/bin/../lib/clang/2.9
-dependency-file \
/Users/void/llvm/llvm.obj/tools/clang/lib/Frontend/Debug+Asserts/FrontendAction.d.tmp
-MP -MT \
/Users/void/llvm/llvm.obj/tools/clang/lib/Frontend/Debug+Asserts/FrontendAction.o
-MT \
/Users/void/llvm/llvm.obj/tools/clang/lib/Frontend/Debug+Asserts/FrontendAction.d
-D _DEBUG -D _GNU_SOURCE \
-D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I
/Users/void/llvm/llvm.obj/include \
-I /Users/void/llvm/llvm.obj/tools/clang/lib/Frontend -I
/Users/void/llvm/llvm.src/include \
-I /Users/void/llvm/llvm.src/tools/clang/lib/Frontend \
-I /Users/void/llvm/llvm.src/tools/clang/lib/Frontend/../../include \
-I /Users/void/llvm/llvm.obj/tools/clang/lib/Frontend/../../include
-Woverloaded-virtual -Wcast-qual \
-Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic
-ferror-limit 19 \
-fmessage-length 124 -stack-protector 1 -fblocks -fno-rtti -fno-common
-fdiagnostics-show-option \
-fcolor-diagnostics /Users/void/llvm/FrontendAction.ii -x c++
Assertion failed: (FieldOffset % CharWidth == 0 && "Field offset not at char
boundary!"), function getFieldOffset, file
/Users/void/llvm/llvm-tot.src/tools/clang/lib/AST/RecordLayoutBuilder.cpp, line
98.
0  clang             0x00000001013f1c32 PrintStackTrace(void*) + 34
1  clang             0x00000001013f2a83 SignalHandler(int) + 707
2  libSystem.B.dylib 0x00007fff8439435a _sigtramp + 26
3  libSystem.B.dylib 0x00007fff5fbfae10 _sigtramp + 3683019472
4  clang             0x0000000100017842 __assert_rtn + 66
5  clang             0x00000001007c6fb4 (anonymous
namespace)::EmptySubobjectMap::UpdateEmptyFieldSubobjects(clang::CXXRecordDecl
const*, clang::CXXRecordDecl const*, clang::CharUnits) + 1284
6  clang             0x00000001007c70da (anonymous
namespace)::EmptySubobjectMap::UpdateEmptyFieldSubobjects(clang::FieldDecl
const*, clang::CharUnits) + 106
7  clang             0x00000001007c7eeb (anonymous
namespace)::RecordLayoutBuilder::LayoutField(clang::FieldDecl const*) + 1403
8  clang             0x00000001007c88da (anonymous
namespace)::RecordLayoutBuilder::LayoutFields(clang::RecordDecl const*) + 58
9  clang             0x00000001007c2b62 (anonymous
namespace)::RecordLayoutBuilder::Layout(clang::CXXRecordDecl const*) + 50
10 clang             0x00000001007c3bae
clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) + 2798
11 clang             0x00000001002622dc
clang::CodeGen::CGRecordLayoutBuilder::Layout(clang::RecordDecl const*) + 28
12 clang             0x0000000100262f77
clang::CodeGen::CodeGenTypes::ComputeRecordLayout(clang::RecordDecl const*) +
263
13 clang             0x00000001002a9f6c
clang::CodeGen::CodeGenTypes::ConvertTagDeclType(clang::TagDecl const*) + 1484
14 clang             0x00000001002a844b
clang::CodeGen::CodeGenTypes::ConvertNewType(clang::QualType) + 1195
15 clang             0x00000001002a9435
clang::CodeGen::CodeGenTypes::ConvertTypeRecursive(clang::QualType) + 437
16 clang             0x00000001002aa8b8
clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType, bool) + 24
17 clang             0x00000001002aaa72
clang::CodeGen::CodeGenTypes::ConvertTypeForMem(clang::QualType, bool) + 34
18 clang             0x00000001002aab22
clang::CodeGen::CodeGenTypes::HandleLateResolvedPointers() + 66
19 clang             0x0000000100192a23
clang::CodeGen::CodeGenTypes::getFunctionInfo(clang::CanQual<clang::Type>,
llvm::SmallVectorImpl<clang::CanQual<clang::Type> > const&,
clang::FunctionType::ExtInfo const&, bool) + 1331
20 clang             0x00000001001935e2
clang::CodeGen::CodeGenTypes::getFunctionInfo(clang::CXXConstructorDecl const*,
clang::CXXCtorType) + 562
21 clang             0x000000010018ece0
clang::CodeGen::CodeGenModule::GetAddrOfCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType) + 192
22 clang             0x000000010018f358
clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType) + 136
23 clang             0x00000001002a163a
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 362
24 clang             0x00000001002a17d6
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 150
25 clang             0x000000010018dfc8
clang::CodeGen::CodeGenModule::EmitCXXConstructors(clang::CXXConstructorDecl
const*) + 40
26 clang             0x00000001002a2489
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 1017
27 clang             0x00000001002c48cc (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 60
28 clang             0x000000010028c56b (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 155
29 clang             0x00000001002d0af6 clang::ParseAST(clang::Sema&, bool) +
182
30 clang             0x000000010028cdec clang::CodeGenAction::ExecuteAction() +
60
31 clang             0x000000010004e169
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393
32 clang             0x00000001000211ce
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1614
33 clang             0x00000001000191e3 cc1_main(char const**, char const**,
char const*, void*) + 515
34 clang             0x0000000100020154 main + 4884
35 clang             0x0000000100017bb8 start + 52
Stack dump:
0.    Program arguments:
/Users/void/llvm/llvm-opt.obj/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free -main-file-name
FrontendAction.cpp -pic-level 1 -mdisable-fp-elim -relaxed-aliasing
-masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.14 -g
-resource-dir
/Users/void/llvm/llvm-opt.obj/Release+Asserts/bin/../lib/clang/2.9
-dependency-file
/Users/void/llvm/llvm.obj/tools/clang/lib/Frontend/Debug+Asserts/FrontendAction.d.tmp
-MP -MT
/Users/void/llvm/llvm.obj/tools/clang/lib/Frontend/Debug+Asserts/FrontendAction.o
-MT
/Users/void/llvm/llvm.obj/tools/clang/lib/Frontend/Debug+Asserts/FrontendAction.d
-D _DEBUG -D _GNU_SOURCE -D __STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I
/Users/void/llvm/llvm.obj/include -I
/Users/void/llvm/llvm.obj/tools/clang/lib/Frontend -I
/Users/void/llvm/llvm.src/include -I
/Users/void/llvm/llvm.src/tools/clang/lib/Frontend -I
/Users/void/llvm/llvm.src/tools/clang/lib/Frontend/../../include -I
/Users/void/llvm/llvm.obj/tools/clang/lib/Frontend/../../include
-Woverloaded-virtual -Wcast-qual -Wno-long-long -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -ferror-limit 19 -fmessage-length 124
-stack-protector 1 -fblocks -fno-rtti -fno-common -fdiagnostics-show-option
-fcolor-diagnostics /Users/void/llvm/FrontendAction.ii -x c++ 
1.   
/Users/void/llvm/llvm.src/tools/clang/lib/Frontend/FrontendAction.cpp:79:1:
current parser token 'FrontendAction'
2.   
/Users/void/llvm/llvm.src/tools/clang/lib/Frontend/FrontendAction.cpp:77:17:
LLVM IR generation of declaration 'clang::FrontendAction::FrontendAction'
3.   
/Users/void/llvm/llvm.src/tools/clang/lib/Frontend/FrontendAction.cpp:77:17:
Generating code for declaration 'clang::FrontendAction::FrontendAction'
Illegal 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  Mon Nov  1 03:57:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 03:57:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8520] New: Win32/Path.inc: "NUL" is not regular
 file (clang -o NUL fails)
Message-ID: <bug-8520-206@http.llvm.org/bugs/>

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

           Summary: Win32/Path.inc: "NUL" is not regular file (clang -o
                    NUL fails)
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu


C:\path\to> clang foo.c -S -o nul
error: unable to rename temporary 'nul-000000' to output file 'nul': 'Can't
move

      'nul-000000' to 'nul': Cannot create a file when that file already
exists.

'
1 error generated.
clang: error: unable to remove file:

===

It is due to sys::Path::isRegularFile().

My workaround is below. It seems there is no way to detect
reserved filenames ("nul", "con", &c) with Win32API.

--- a/lib/System/Win32/Path.inc
+++ b/lib/System/Win32/Path.inc
@@ -369,6 +369,9 @@ bool
 Path::isRegularFile() const {
   if (isDirectory())
     return false;
+  if (getBasename().size() == 3
+      && memcmp(getBasename().data(), "nul", 3) == 0)
+    return false;
   return true;
 }

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

From bugzilla-daemon at llvm.org  Mon Nov  1 06:28:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 06:28:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8521] New: NEON instruction VQSHLU producing bad
	cast
Message-ID: <bug-8521-206@http.llvm.org/bugs/>

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

           Summary: NEON instruction VQSHLU producing bad cast
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rengolin at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When lowering vqshlu_n_s8() (file attached), Clang breaks with bad cast.

Command line:
$ clang -ccc-host-triple armv7a-none-eabi -ccc-gcc-name arm-none-eabi-gcc
-mfloat-abi=hard -w -emit-llvm -mcpu=cortex-a8 -S vqshlu_n.c -o -

Error:
clang: Constants.cpp:1174: static llvm::Constant*
llvm::ConstantExpr::getCast(unsigned int, llvm::Constant*, const llvm::Type*):
Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"'
failed.
(...)
7  clang           0x00000000007c2885 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateCast(llvm::Instruction::CastOps, llvm::Value*, llvm::Type const*,
llvm::Twine const&) + 101
8  clang           0x00000000008fd4ae
clang::CodeGen::CodeGenFunction::EmitNeonCall(llvm::Function*,
llvm::SmallVectorImpl<llvm::Value*>&, char const*, bool, unsigned int, bool) +
238
(...)

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

From bugzilla-daemon at llvm.org  Mon Nov  1 10:15:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 10:15:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8519] Field offset not at char boundary!
In-Reply-To: <bug-8519-206@http.llvm.org/bugs/>
References: <bug-8519-206@http.llvm.org/bugs/>
Message-ID: <20101101151544.A96112A6C12D@llvm.org>

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

Anders Carlsson <andersca at mac.com> changed:

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

--- Comment #2 from Anders Carlsson <andersca at mac.com> 2010-11-01 10:15:43 CDT ---
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20101101/035963.html

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

From bugzilla-daemon at llvm.org  Mon Nov  1 10:21:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 10:21:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8522] New: Use-after-free in VMCore library
 (ConstantUniqueMap::refineAbstractType)
Message-ID: <bug-8522-206@http.llvm.org/bugs/>

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

           Summary: Use-after-free in VMCore library
                    (ConstantUniqueMap::refineAbstractType)
           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: Tim.Deegan at citrix.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5713)
 --> (http://llvm.org/bugs/attachment.cgi?id=5713)
Possible fix?

When ConstantUniqueMap::refineAbstractType() deletes an InlineAsm constant, it
seems like it can find the same constant again later in its main loop.

I was able to repro this (on trunk and on 2.8) when linking parts of the Xen
hypervisor, which would cause llvm-ld to segfault:

whitby:link$ llvm-ld -r -o test.o domain.o memory.o 
0  llvm-ld         0x0000000000c42ff2
1  llvm-ld         0x0000000000c42de5
2  libpthread.so.0 0x00007f9b55b3ef60
3  libpthread.so.0 0x00000000025394d0
Stack dump:
0.      Program arguments: llvm-ld -r -o test.o domain.o memory.o 
Segmentation fault

I can supply the actual .o files if needed.

The problem seems to be that other constant types make an effort to remove
themselves cleanly from datastructures but InlineAsms just delete themselves. 
By cargo-culting other constant types  I found the attached patch fixes the
crash but I have no great faith in its correctness. :)

Cheers,

Tim.

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

From bugzilla-daemon at llvm.org  Mon Nov  1 10:47:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 10:47:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7459] [MC] llvm-mc movsx/movzx not recognized
In-Reply-To: <bug-7459-206@http.llvm.org/bugs/>
References: <bug-7459-206@http.llvm.org/bugs/>
Message-ID: <20101101154713.50F4E2A6C12E@llvm.org>

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

Daniel Dunbar <daniel at zuster.org> 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 Nov  1 11:05:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 11:05:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8523] New: build failure on Debian Testing,
 not seen on CentOS 5
Message-ID: <bug-8523-206@http.llvm.org/bugs/>

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

           Summary: build failure on Debian Testing, not seen on CentOS 5
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: herrold at owlriver.com
                CC: llvmbugs at cs.uiuc.edu


herrold at debian4:~/temp$ ./mk-clang.sh clang-20101101.tar.gz
20101101
tail: cannot open `clang-20101101/debian/changelog' for reading: No such file
or directory
dpkg-source: failure: tail of clang-20101101/debian/changelog gave error exit
status 1
Makefile:44: Makefile.config: No such file or directory
Makefile:130: /Makefile.rules: No such file or directory
make: *** No rule to make target `/Makefile.rules'.  Stop.
Maintainer name : herrold
Email-Address   : info at owlriver.com
Date            : Mon, 01 Nov 2010 10:14:05 -0400
Package Name    : clang-0.0.20101101-1
Version         : 20101101
License         : gpl
Using dpatch    : no
Type of Package : Multi-Binary
Hit <enter> to confirm: Done. Please edit the files in the debian/ subdirectory
now. clang-0.0.20101101-1
uses a configure script, so you probably don't have to edit the Makefiles.
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `global constructors keyed to Hello.cpp':
Hello.cpp:(.text+0x8b): undefined reference to
`llvm::PassRegistry::getPassRegistry()'
Hello.cpp:(.text+0x9f): undefined reference to
`llvm::PassRegistry::registerPass(llvm::PassInfo const&, bool)'
Hello.cpp:(.text+0x129): undefined reference to
`llvm::PassRegistry::getPassRegistry()'
Hello.cpp:(.text+0x13d): undefined reference to
`llvm::PassRegistry::registerPass(llvm::PassInfo const&, bool)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `(anonymous namespace)::Hello::~Hello()':
Hello.cpp:(.text+0x1dc): undefined reference to `vtable for llvm::FunctionPass'
Hello.cpp:(.text+0x1e9): undefined reference to `llvm::Pass::~Pass()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `(anonymous namespace)::Hello::~Hello()':
Hello.cpp:(.text+0x225): undefined reference to `vtable for llvm::FunctionPass'
Hello.cpp:(.text+0x232): undefined reference to `llvm::Pass::~Pass()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `(anonymous namespace)::Hello2::~Hello2()':
Hello.cpp:(.text+0x25c): undefined reference to `vtable for llvm::FunctionPass'
Hello.cpp:(.text+0x269): undefined reference to `llvm::Pass::~Pass()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `(anonymous namespace)::Hello2::~Hello2()':
Hello.cpp:(.text+0x2a5): undefined reference to `vtable for llvm::FunctionPass'
Hello.cpp:(.text+0x2b2): undefined reference to `llvm::Pass::~Pass()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `llvm::Pass* llvm::callDefaultCtor<(anonymous
namespace)::Hello>()':
Hello.cpp:(.text+0x2fa): undefined reference to
`llvm::Pass::Pass(llvm::PassKind, char&)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `llvm::Pass* llvm::callDefaultCtor<(anonymous
namespace)::Hello2>()':
Hello.cpp:(.text+0x35a): undefined reference to
`llvm::Pass::Pass(llvm::PassKind, char&)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `(anonymous namespace)::Hello2::runOnFunction(llvm::Function&)':
Hello.cpp:(.text+0x39b): undefined reference to
`llvm::sys::AtomicIncrement(unsigned int volatile*)'
Hello.cpp:(.text+0x3a7): undefined reference to `llvm::sys::MemoryFence()'
Hello.cpp:(.text+0x3b8): undefined reference to
`llvm::Statistic::RegisterStatistic()'
Hello.cpp:(.text+0x3bd): undefined reference to `llvm::errs()'
Hello.cpp:(.text+0x3f2): undefined reference to `llvm::Value::getName() const'
Hello.cpp:(.text+0x402): undefined reference to `llvm::errs()'
Hello.cpp:(.text+0x412): undefined reference to
`llvm::raw_ostream::write_escaped(llvm::StringRef)'
Hello.cpp:(.text+0x44e): undefined reference to `llvm::raw_ostream::write(char
const*, unsigned int)'
Hello.cpp:(.text+0x464): undefined reference to
`llvm::raw_ostream::write(unsigned char)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:
In function `(anonymous namespace)::Hello::runOnFunction(llvm::Function&)':
Hello.cpp:(.text+0x49b): undefined reference to
`llvm::sys::AtomicIncrement(unsigned int volatile*)'
Hello.cpp:(.text+0x4a7): undefined reference to `llvm::sys::MemoryFence()'
Hello.cpp:(.text+0x4b8): undefined reference to
`llvm::Statistic::RegisterStatistic()'
Hello.cpp:(.text+0x4bd): undefined reference to `llvm::errs()'
Hello.cpp:(.text+0x4f2): undefined reference to `llvm::Value::getName() const'
Hello.cpp:(.text+0x502): undefined reference to `llvm::errs()'
Hello.cpp:(.text+0x512): undefined reference to
`llvm::raw_ostream::write_escaped(llvm::StringRef)'
Hello.cpp:(.text+0x54e): undefined reference to `llvm::raw_ostream::write(char
const*, unsigned int)'
Hello.cpp:(.text+0x564): undefined reference to
`llvm::raw_ostream::write(unsigned char)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x10):
undefined reference to `llvm::Pass::getPassName() const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x18):
undefined reference to `llvm::Pass::print(llvm::raw_ostream&, llvm::Module
const*) const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x1c):
undefined reference to
`llvm::FunctionPass::createPrinterPass(llvm::raw_ostream&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x20):
undefined reference to `llvm::FunctionPass::assignPassManager(llvm::PMStack&,
llvm::PassManagerType)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x24):
undefined reference to `llvm::Pass::preparePassManager(llvm::PMStack&)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x28):
undefined reference to `llvm::FunctionPass::getPotentialPassManagerType()
const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x2c):
undefined reference to `llvm::Pass::getAnalysisUsage(llvm::AnalysisUsage&)
const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x30):
undefined reference to `llvm::Pass::releaseMemory()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x34):
undefined reference to `llvm::Pass::getAdjustedAnalysisPointer(void const*)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x38):
undefined reference to `llvm::Pass::getAsImmutablePass()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x3c):
undefined reference to `llvm::Pass::getAsPMDataManager()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x40):
undefined reference to `llvm::Pass::verifyAnalysis() const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x44):
undefined reference to `llvm::Pass::dumpPassStructure(unsigned int)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x48):
undefined reference to `llvm::FunctionPass::doInitialization(llvm::Module&)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x50):
undefined reference to `llvm::FunctionPass::doFinalization(llvm::Module&)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x70):
undefined reference to `llvm::Pass::getPassName() const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x78):
undefined reference to `llvm::Pass::print(llvm::raw_ostream&, llvm::Module
const*) const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x7c):
undefined reference to
`llvm::FunctionPass::createPrinterPass(llvm::raw_ostream&,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x80):
undefined reference to `llvm::FunctionPass::assignPassManager(llvm::PMStack&,
llvm::PassManagerType)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x84):
undefined reference to `llvm::Pass::preparePassManager(llvm::PMStack&)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x88):
undefined reference to `llvm::FunctionPass::getPotentialPassManagerType()
const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x90):
undefined reference to `llvm::Pass::releaseMemory()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x94):
undefined reference to `llvm::Pass::getAdjustedAnalysisPointer(void const*)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x98):
undefined reference to `llvm::Pass::getAsImmutablePass()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0x9c):
undefined reference to `llvm::Pass::getAsPMDataManager()'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0xa0):
undefined reference to `llvm::Pass::verifyAnalysis() const'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0xa4):
undefined reference to `llvm::Pass::dumpPassStructure(unsigned int)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0xa8):
undefined reference to `llvm::FunctionPass::doInitialization(llvm::Module&)'
/home/herrold/temp/clang-20101101/lib/Transforms/Hello/Release+Asserts/Hello.o:(.data.rel.ro+0xb0):
undefined reference to `llvm::FunctionPass::doFinalization(llvm::Module&)'
collect2: ld returned 1 exit status
make[4]: ***
[/home/herrold/temp/clang-20101101/Release+Asserts/lib/LLVMHello.so] Error 1
make[3]: *** [Hello/.makeinstall] Error 2
make[2]: *** [Transforms/.makeinstall] Error 2
make[1]: *** [install] Error 1
make: *** [install-arch] Error 2
make[1]: *** No rule to make target `distclean'.  Stop.
make: *** [clean] Error 2
herrold at debian4:~/temp$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
herrold at debian4:~/temp$ uname -a
Linux debian4.first.lan 2.6.26-2-686 #1 SMP Mon Aug 30 07:01:57 UTC 2010 i686
GNU/Linux
herrold at debian4:~/temp$

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

From bugzilla-daemon at llvm.org  Mon Nov  1 12:56:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 12:56:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7459] [MC] llvm-mc movsx/movzx not recognized
In-Reply-To: <bug-7459-206@http.llvm.org/bugs/>
References: <bug-7459-206@http.llvm.org/bugs/>
Message-ID: <20101101175630.ADBAC2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-11-01 12:56:30 CDT ---
We correctly reject that. GAS has a bug when processing instructions like
"movsx (mem), %rax".  The instruction doesn't specify a size (it could
reasonably be 8 bits, 16 bits, or 32-bits) so gas just picks a random one.  It
is better for llvm to reject it and force projects to make their assumptions
explicit.

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

From bugzilla-daemon at llvm.org  Mon Nov  1 13:20:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 13:20:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7916] clang c++ crash in name lookup with unusual
 inheritance structure
In-Reply-To: <bug-7916-206@http.llvm.org/bugs/>
References: <bug-7916-206@http.llvm.org/bugs/>
Message-ID: <20101101182059.8CB442A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-01 13:20:59 CDT ---
I recently fixed a very similar bug in this area; it was likely a duplicate of
this bug, which I missed. Closing...

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

From bugzilla-daemon at llvm.org  Mon Nov  1 15:00:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 15:00:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8524] New: [inline asm] spandsp compilation failure
Message-ID: <bug-8524-206@http.llvm.org/bugs/>

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

           Summary: [inline asm] spandsp compilation failure
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ojab at ojab.ru
                CC: llvmbugs at cs.uiuc.edu


clang version 2.9 (trunk 117924)
Target: x86_64-unknown-linux-gnu
Thread model: posix

gsm0610_rpe.c:78:9: error: invalid operand for instruction
        " emms;\n"
        ^
<inline asm>:8:2: note: instantiated into assembly here
 movq %rax,%mm5;
 ^
1 error generated.

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

From bugzilla-daemon at llvm.org  Mon Nov  1 15:21:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 15:21:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8525] New: False positive due to analyzer
 suggesting impossible flow
Message-ID: <bug-8525-206@http.llvm.org/bugs/>

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

           Summary: False positive due to analyzer suggesting impossible
                    flow
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: alexei.svitkine at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Consider the following simple example:

int foo(char *start)
{
    int result;
    char *end = start + 1;
    char *index = start;

    if (start == (char*)-1)
        return -1;

    while (index < end) {
        result = 0;
        break;
     }

    return result;
}


Clang analyzer warns:

mytest.c:16:2: warning: Undefined or garbage value returned to caller
        return result;
        ^      ~~~~~~

This is a false positive. Clang considers the case where the loop body is never
entered.

In this case, this cannot happen. There are two possibilities, either "end ==
start + 1", or "start + 1" resulted in an overflow and end == 0.

The overflow case is detected by:

    if (start == (char*)-1)
        return -1;

So if we don't hit that, we will always execute the loop body.

The problem also happens if the overflow check is modified to be:

    if (end == 0)
        return -1;

Now, let's consider for a moment the hypothetical case where analyzer is fixed
to detect the overflow check above and do the right thing (not warn because of
it).

I want to argue that even without the overflow check in place, clang should
still do something different here.

Either it should not warn at all (because something like start + 1 is unlikely
to overflow and cause this code to misbehave), or it should say "assuming
integer overflow" as one of the steps leading up to the analysis warning.

This should also be the case if the value being added is any unsigned integer
(coming from a variable), and not just a literal 1 as is the case in my
example.

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

From bugzilla-daemon at llvm.org  Mon Nov  1 18:46:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 18:46:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7287] Analyzer/C++ Crash: "Name is not a simple
 identifier" for implicit operator= with array elements
In-Reply-To: <bug-7287-206@http.llvm.org/bugs/>
References: <bug-7287-206@http.llvm.org/bugs/>
Message-ID: <20101101234653.DDC3E2A6C124@llvm.org>

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

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> 2010-11-01 18:46:53 CDT ---
Fixed in Clang r117970 by Jim Goodnow 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  Mon Nov  1 19:08:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 19:08:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8462] Argument deduction failure in function
	templates
In-Reply-To: <bug-8462-206@http.llvm.org/bugs/>
References: <bug-8462-206@http.llvm.org/bugs/>
Message-ID: <20101102000810.EBC512A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-11-01 19:08:10 CDT ---
Committed in Clang r117983, 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 Nov  1 21:36:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  1 Nov 2010 21:36:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7897] clang c++ crash in asm with temporary with
 non-trivial destructor
In-Reply-To: <bug-7897-206@http.llvm.org/bugs/>
References: <bug-7897-206@http.llvm.org/bugs/>
Message-ID: <20101102023610.ADD942A6C12E@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #1 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2010-11-01 21:36:10 CDT ---
Fixed at r118001.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 02:09:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 02:09:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8526] New: anonymous namespace prevents codegen
 outside namespace
Message-ID: <bug-8526-206@http.llvm.org/bugs/>

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

           Summary: anonymous namespace prevents codegen outside namespace
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: skabet at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


$ clang++ --version
clang version 2.9 (trunk 118011)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ clang++ -c bug.cpp -o out.o && nm out.o
$
(empty output)

$ cat bug.cpp
namespace { // removing namespace makes it work
  class Inner {
  };
}

template<class D>
class _Outer{

public:
  _Outer() {}
};

typedef _Outer<Inner> Outer;

class Foo {
public:
  Outer bar() const;
};

Outer Foo::bar() const { // not emited. "nm out.o" is empty
  return Outer(); 
}

============

As seen, Foo::bar is not emited. Removing the anonymous namespace makes it
work. Changing the return type (Outer) to something not related the the
anonymous namespace also makes it 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  Tue Nov  2 03:04:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 03:04:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8527] New: Win32/Process.inc: "NUL" is not display
 device(opt -o nul fails)
Message-ID: <bug-8527-206@http.llvm.org/bugs/>

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

           Summary: Win32/Process.inc: "NUL" is not display device(opt -o
                    nul fails)
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ Release+Asserts/bin/opt.exe a.ll -o nul
WARNING: You're attempting to print out a bitcode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bitcode first-hand, you
can force output with the `-f' option.

===

Also NUL is character device. GetFileType(h) cannot distinguish whether h is
console handle or not.

Proposal patch;

--- a/lib/System/Win32/Process.inc
+++ b/lib/System/Win32/Process.inc
@@ -132,7 +132,8 @@ bool Process::StandardErrIsDisplayed() {
 }

 bool Process::FileDescriptorIsDisplayed(int fd) {
-  return GetFileType((HANDLE)_get_osfhandle(fd)) == FILE_TYPE_CHAR;
+  DWORD Mode;  // Unused
+  return (GetConsoleMode((HANDLE)_get_osfhandle(fd), &Mode) != 0);
 }

 unsigned Process::StandardOutColumns() {

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

From bugzilla-daemon at llvm.org  Tue Nov  2 06:19:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 06:19:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8528] New: [REGRESSION]dct64_sse.c from MPlayer is
	miscompiled
Message-ID: <bug-8528-206@http.llvm.org/bugs/>

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

           Summary: [REGRESSION]dct64_sse.c from MPlayer is miscompiled
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu


Hi;

Looks like dct64_sse.c from MPlayer is miscompilled, resulting in garbage audio
with mp3 streams.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 06:29:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 06:29:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8529] New: Suboptimal diagnostic produced when ADL
 would find a constructor
Message-ID: <bug-8529-206@http.llvm.org/bugs/>

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

           Summary: Suboptimal diagnostic produced when ADL would find a
                    constructor
           Product: clang
           Version: 2.8
          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


Older versions of g++ erroneously allow argument-dependent lookup to find
constructors. If code which relies on this is run through clang, the error
message does not make it obvious why the code is rejected. For instance:

namespace N {
  enum E { e };
  struct C {
    C(E = e) {}
  };
}

int main() {
  (void)C(N::e);
}

Modern version of g++ (4.2 and later) produce this error:

adl.cpp: In function ?int main()?:
adl.cpp:3: error: argument dependent lookup finds ?struct N::C?
adl.cpp:9: error:   in call to ?C?

clang produces this error:

adl.cpp:9:9: error: use of undeclared identifier 'C'
  (void)C(N::e);
        ^
1 error generated.

It'd be nice if clang could go the extra mile and say something like:

adl.cpp:9:9: error: constructors cannot be called via argument-dependent lookup
  (void)C(N::e);
        ^
        N::

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

From bugzilla-daemon at llvm.org  Tue Nov  2 07:11:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 07:11:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8530] New: Clang rejects enum comparison operators
Message-ID: <bug-8530-206@http.llvm.org/bugs/>

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

           Summary: Clang rejects enum comparison operators
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mikazkow at tlen.pl
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This is similar to #7319, but there it was a templated operator.

Source:

enum A{X,Y};
bool operator<(A,A);
int main() {
 return X<Y;
}

Result:
<stdin>:4:10: error: use of overloaded operator '<' is ambiguous
 return X<Y;
        ~^~
<stdin>:2:6: note: candidate function
bool operator<(A,A);
     ^
<stdin>:4:10: note: built-in candidate operator<(enum A, enum A)
 return X<Y;
         ^
<stdin>:4:10: note: built-in candidate operator<(int, int)
<stdin>:4:10: note: built-in candidate operator<(double, int)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, int)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, int)
<stdin>:4:10: note: built-in candidate operator<(long double, int)
<stdin>:4:10: note: built-in candidate operator<(long long, int)
<stdin>:4:10: note: built-in candidate operator<(float, int)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, int)
<stdin>:4:10: note: built-in candidate operator<(long, int)
<stdin>:4:10: note: built-in candidate operator<(int, long)
<stdin>:4:10: note: built-in candidate operator<(int, long long)
<stdin>:4:10: note: built-in candidate operator<(int, unsigned int)
<stdin>:4:10: note: built-in candidate operator<(int, unsigned long)
<stdin>:4:10: note: built-in candidate operator<(int, unsigned long long)
<stdin>:4:10: note: built-in candidate operator<(int, float)
<stdin>:4:10: note: built-in candidate operator<(int, double)
<stdin>:4:10: note: built-in candidate operator<(int, long double)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, double)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, long
double)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, float)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, unsigned
long long)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, unsigned
long)
<stdin>:4:10: note: built-in candidate operator<(float, long)
<stdin>:4:10: note: built-in candidate operator<(float, long long)
<stdin>:4:10: note: built-in candidate operator<(float, unsigned int)
<stdin>:4:10: note: built-in candidate operator<(float, unsigned long)
<stdin>:4:10: note: built-in candidate operator<(float, unsigned long long)
<stdin>:4:10: note: built-in candidate operator<(float, float)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, unsigned
int)
<stdin>:4:10: note: built-in candidate operator<(float, double)
<stdin>:4:10: note: built-in candidate operator<(long double, long double)
<stdin>:4:10: note: built-in candidate operator<(long double, double)
<stdin>:4:10: note: built-in candidate operator<(long double, float)
<stdin>:4:10: note: built-in candidate operator<(long double, unsigned long
long)
<stdin>:4:10: note: built-in candidate operator<(long double, unsigned long)
<stdin>:4:10: note: built-in candidate operator<(long double, unsigned int)
<stdin>:4:10: note: built-in candidate operator<(long double, long long)
<stdin>:4:10: note: built-in candidate operator<(long double, long)
<stdin>:4:10: note: built-in candidate operator<(double, long double)
<stdin>:4:10: note: built-in candidate operator<(double, double)
<stdin>:4:10: note: built-in candidate operator<(double, float)
<stdin>:4:10: note: built-in candidate operator<(double, unsigned long long)
<stdin>:4:10: note: built-in candidate operator<(double, unsigned long)
<stdin>:4:10: note: built-in candidate operator<(double, unsigned int)
<stdin>:4:10: note: built-in candidate operator<(double, long long)
<stdin>:4:10: note: built-in candidate operator<(double, long)
<stdin>:4:10: note: built-in candidate operator<(float, long double)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, long)
<stdin>:4:10: note: built-in candidate operator<(long long, long double)
<stdin>:4:10: note: built-in candidate operator<(long long, double)
<stdin>:4:10: note: built-in candidate operator<(long long, float)
<stdin>:4:10: note: built-in candidate operator<(long long, unsigned long long)
<stdin>:4:10: note: built-in candidate operator<(long long, unsigned long)
<stdin>:4:10: note: built-in candidate operator<(long long, unsigned int)
<stdin>:4:10: note: built-in candidate operator<(long long, long long)
<stdin>:4:10: note: built-in candidate operator<(long long, long)
<stdin>:4:10: note: built-in candidate operator<(long, long double)
<stdin>:4:10: note: built-in candidate operator<(long, double)
<stdin>:4:10: note: built-in candidate operator<(long, float)
<stdin>:4:10: note: built-in candidate operator<(long, unsigned long long)
<stdin>:4:10: note: built-in candidate operator<(long, unsigned long)
<stdin>:4:10: note: built-in candidate operator<(long, unsigned int)
<stdin>:4:10: note: built-in candidate operator<(long, long long)
<stdin>:4:10: note: built-in candidate operator<(long, long)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, long long)
<stdin>:4:10: note: built-in candidate operator<(unsigned long long, long)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, long double)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, double)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, float)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, unsigned long
long)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, unsigned long)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, unsigned int)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, long long)
<stdin>:4:10: note: built-in candidate operator<(unsigned long, long)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, long double)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, double)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, float)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, unsigned long
long)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, unsigned long)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, unsigned int)
<stdin>:4:10: note: built-in candidate operator<(unsigned int, long long)
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  Tue Nov  2 07:31:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 07:31:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8531] New: clang cannot color diagnostics when
 output is not going to a terminal
Message-ID: <bug-8531-206@http.llvm.org/bugs/>

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

           Summary: clang cannot color diagnostics when output is not
                    going to a terminal
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


clang's compiler driver (lib/Driver/Tools.cpp:1478 or so) refuses to pass
-fcolor-diagnostics on to cc1 if stderr is not a tty. This means you can't get
colored diagnostics out of clang if you're running it through distcc or another
compilation distribution system which doesn't allocate a pty.

It would seem more reasonable to say:
  * if -fno-color-diagnostics is given to the driver, never color diagnostics
  * if -fcolor-diagnostics is given to the driver, always color diagnostics
  * if neither is given, color diagnostics iff stderr is a tty which supports
colors.
Indeed, the comment seems to suggest that this was the intention.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 07:33:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 07:33:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8531] clang cannot color diagnostics when output is
 not going to a terminal
In-Reply-To: <bug-8531-206@http.llvm.org/bugs/>
References: <bug-8531-206@http.llvm.org/bugs/>
Message-ID: <20101102123326.0DCBA2A6C124@llvm.org>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2010-11-02 07:33:25 CDT ---
Pulled up the latest svn to try to fix this and found it's already fixed in
TOT!

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

From bugzilla-daemon at llvm.org  Tue Nov  2 10:30:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 10:30:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8526] anonymous namespace prevents codegen outside
	namespace
In-Reply-To: <bug-8526-206@http.llvm.org/bugs/>
References: <bug-8526-206@http.llvm.org/bugs/>
Message-ID: <20101102153028.234FD2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-02 10:30:27 CDT ---
Clang is doing the right thing here. The code is well-formed, as far as I can
tell. However, Clang is not emitting Foo::bar() because it has internal linkage
and is never used. If you add an external function that calls it, e.g.,

  void blah() {
    Foo f;
    f.bar();
  }

then Clang will generate code for Foo::bar().

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

From bugzilla-daemon at llvm.org  Tue Nov  2 10:51:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 10:51:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7190] clang crashes trying to instantiate an
 invalid friend decl
In-Reply-To: <bug-7190-206@http.llvm.org/bugs/>
References: <bug-7190-206@http.llvm.org/bugs/>
Message-ID: <20101102155133.1466C2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2010-11-02 10:51:31 CDT ---
The diagnostics are correct. Closing.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 10:59:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 10:59:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7325] Clang too permissive with use of member
 function lacking a call
In-Reply-To: <bug-7325-206@http.llvm.org/bugs/>
References: <bug-7325-206@http.llvm.org/bugs/>
Message-ID: <20101102155921.E6E0E2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-02 10:59:21 CDT ---
Argiris fixed this recently, IIRC. As of Clang r118001 we get:

t.cpp:6:9: error: a bound member function may only be used to call it
    if (xp->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  Tue Nov  2 11:00:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:00:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7364] #pragma pack(1) needs to be supported
In-Reply-To: <bug-7364-206@http.llvm.org/bugs/>
References: <bug-7364-206@http.llvm.org/bugs/>
Message-ID: <20101102160056.2F2C52A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-11-02 11:00:55 CDT ---
Closing, since #pragma pack has been working for a very long time and there is
no specific test case here.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 11:02:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:02:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8517] return type not recognized in out of line
	definition
In-Reply-To: <bug-8517-206@http.llvm.org/bugs/>
References: <bug-8517-206@http.llvm.org/bugs/>
Message-ID: <20101102160231.B798B2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-02 11:02:31 CDT ---
Ah, this is another instance of

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

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

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

From bugzilla-daemon at llvm.org  Tue Nov  2 11:20:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:20:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7898] clang c++ crash with invalid reference to
	member function
In-Reply-To: <bug-7898-206@http.llvm.org/bugs/>
References: <bug-7898-206@http.llvm.org/bugs/>
Message-ID: <20101102162054.671D52A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-02 11:20:53 CDT ---
We no longer crash. I think Argiris fixed this recently:


t.cpp:8:12: error: cannot initialize a variable of type 'int (A::*)(int)' with
      an lvalue of type '<overloaded function type>'
  int (A::*ptr4) (int) = ns;
           ^             ~~

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

From bugzilla-daemon at llvm.org  Tue Nov  2 11:21:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:21:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7901] clang c++ crash with template instantiated
 with locally-declared extern variable
In-Reply-To: <bug-7901-206@http.llvm.org/bugs/>
References: <bug-7901-206@http.llvm.org/bugs/>
Message-ID: <20101102162148.E11172A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-02 11:21:48 CDT ---
Already fixed in 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  Tue Nov  2 11:25:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:25:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7903] clang c++ infinite loop with recursive
 instantiation of virtual method
In-Reply-To: <bug-7903-206@http.llvm.org/bugs/>
References: <bug-7903-206@http.llvm.org/bugs/>
Message-ID: <20101102162508.47BEF2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-02 11:25:07 CDT ---


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

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

From bugzilla-daemon at llvm.org  Tue Nov  2 11:29:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:29:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7947] crash in DiagnoseEmptyLookup
In-Reply-To: <bug-7947-206@http.llvm.org/bugs/>
References: <bug-7947-206@http.llvm.org/bugs/>
Message-ID: <20101102162945.D51F52A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-02 11:29:45 CDT ---
Looks like this is already fixed.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 11:38:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:38:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7989] access control misapplied to member templates
In-Reply-To: <bug-7989-206@http.llvm.org/bugs/>
References: <bug-7989-206@http.llvm.org/bugs/>
Message-ID: <20101102163805.B82982A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-02 11:38:05 CDT ---
Clang now accepts this.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 11:54:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:54:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8048] clang++ incorrectly deduces template argument
 to local type
In-Reply-To: <bug-8048-206@http.llvm.org/bugs/>
References: <bug-8048-206@http.llvm.org/bugs/>
Message-ID: <20101102165423.5F9F02A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-02 11:54:23 CDT ---
We've decided to have Clang follow the C++0x semantics here, allowing local
types as template arguments. Recently, we added appropriate warnings here:


t.cpp:2:24: warning: template argument uses local type '<anonymous enum at
      t.cpp:2:12>' [-Wlocal-type-template-args]
void g() { enum { E }; f(E); }

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

From bugzilla-daemon at llvm.org  Tue Nov  2 11:56:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 11:56:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7666] Variable size array function parameters cause
 clang to segfault
In-Reply-To: <bug-7666-206@http.llvm.org/bugs/>
References: <bug-7666-206@http.llvm.org/bugs/>
Message-ID: <20101102165638.039FB2A6C12E@llvm.org>

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

Fariborz Jahanian <fjahanian at apple.com> changed:

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

--- Comment #1 from Fariborz Jahanian <fjahanian at apple.com> 2010-11-02 11:56:37 CDT ---
Fixed in TOT: http://llvm.org/viewvc/llvm-project?view=rev&revision=118019

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

From bugzilla-daemon at llvm.org  Tue Nov  2 12:52:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 12:52:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8519] Field offset not at char boundary!
In-Reply-To: <bug-8519-206@http.llvm.org/bugs/>
References: <bug-8519-206@http.llvm.org/bugs/>
Message-ID: <20101102175211.942412A6C12E@llvm.org>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |rafael.espindola at gmail.com
         Resolution|FIXED                       |

--- Comment #3 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-02 12:52:10 CDT ---
-------------------------------------------
class Value {
unsigned char HasValueHandle : 1;
unsigned char SubclassOptionalData : 7;
};
class map     {
};
struct PSVGlobalsTy {
const Value PSVs[4];
map FSValues;
};
static PSVGlobalsTy PSVGlobals;
----------------------------------------------

/usr/local/google/home/espindola/llvm/build/Release+Asserts/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -emit-llvm -o foo.s  PseudoSourceValue.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  Tue Nov  2 13:01:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 13:01:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8522] Use-after-free in VMCore library
 (ConstantUniqueMap::refineAbstractType)
In-Reply-To: <bug-8522-206@http.llvm.org/bugs/>
References: <bug-8522-206@http.llvm.org/bugs/>
Message-ID: <20101102180123.53C882A6C12D@llvm.org>

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

Dale Johannesen <dalej at apple.com> changed:

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

--- Comment #5 from Dale Johannesen <dalej at apple.com> 2010-11-02 13:01:22 CDT ---
I confirmed this patch fixes the problem and doesn't break anything obvious, so
checked in as 118030.  Thanks.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 13:28:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 13:28:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8519] Field offset not at char boundary!
In-Reply-To: <bug-8519-206@http.llvm.org/bugs/>
References: <bug-8519-206@http.llvm.org/bugs/>
Message-ID: <20101102182824.54BB22A6C124@llvm.org>

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

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

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

--- Comment #4 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-02 13:28:23 CDT ---
It was fixed. I accidentally tried an old version of 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  Tue Nov  2 15:02:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 15:02:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8532] New: "clang can't do complex arithmetic"
Message-ID: <bug-8532-206@http.llvm.org/bugs/>

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

           Summary: "clang can't do complex arithmetic"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ed at 80386.nl
                CC: llvmbugs at cs.uiuc.edu


This is a bug report based on an observation from one of our Clang users at
FreeBSD, Steve Kargl. Complete discussion thread can be found here:

http://lists.freebsd.org/pipermail/freebsd-toolchain/2010-November/000001.html

It seems that clang can't do complex arithmetic.
Not to worry gcc in base can't do it either.

/*
 * The C99 standard intends x+I*y to be used for this, but x+I*y is
 * currently unusable because gcc introduces many overflow,
 * underflow, sign and efficiency bugs by rewriting I*y as
 * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product.
 * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted
 * to -0.0+I*0.0.
 */
#include <complex.h>
#include <math.h>
#include <stdio.h>

int main(void) {

  double complex z;
  double x, y;

  x = 0.;
  y = 1. / x;
  x = copysign(x, -1.);

  /* z = 0 + i (-0) */
  z = I * x;
  printf("z = 0 + i (-0) = %e + i (%e)\n", creal(z), cimag(z));

  /* z = 0 + i Inf */
  z = I * y;
  printf("z = 0 + i Inf = %e + i %e\n", creal(z), cimag(z));

}

troutmask:sgk[204] clang -o z z.c -lm && ./z
z = 0 + i (-0) = -0.000000e+00 + i (0.000000e+00)
z = 0 + i Inf = nan + i inf


If I read Annex G in n1256.pdf correctly, the z = I*inf = NaN + I inf
is going to really bad things because the NaN is going to propagate
if z is used in further computations.  Annex G says z is an infinity.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 16:00:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 16:00:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8533] New: Typo on home page: "as a optimizer"
Message-ID: <bug-8533-206@http.llvm.org/bugs/>

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

           Summary: Typo on home page: "as a optimizer"
           Product: Website
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General Website
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Trevor.W.Harmon at nasa.gov
                CC: llvmbugs at cs.uiuc.edu


On http://llvm.org/, "as a optimizer" should be "as an optimizer".

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

From bugzilla-daemon at llvm.org  Tue Nov  2 16:10:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 16:10:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7851] clang++ can't compile CryptoPP 5.6.0
In-Reply-To: <bug-7851-206@http.llvm.org/bugs/>
References: <bug-7851-206@http.llvm.org/bugs/>
Message-ID: <20101102211050.4CA152A6C12E@llvm.org>

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

Fariborz Jahanian <fjahanian at apple.com> changed:

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

--- Comment #6 from Fariborz Jahanian <fjahanian at apple.com> 2010-11-02 16:10:49 CDT ---
Fixed in TOT: http://llvm.org/viewvc/llvm-project?view=rev&revision=118066
Attached test case now moves forward and issues numerous errors.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 16:28:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 16:28:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8533] Typo on home page: "as a optimizer"
In-Reply-To: <bug-8533-206@http.llvm.org/bugs/>
References: <bug-8533-206@http.llvm.org/bugs/>
Message-ID: <20101102212836.E66892A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-02 16:28:36 CDT ---
Fixed in r118071, thanks.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 16:35:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 16:35:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7851] clang++ can't compile CryptoPP 5.6.0
In-Reply-To: <bug-7851-206@http.llvm.org/bugs/>
References: <bug-7851-206@http.llvm.org/bugs/>
Message-ID: <20101102213538.9078E2A6C12E@llvm.org>

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

Fariborz Jahanian <fjahanian at apple.com> changed:

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

--- Comment #7 from Fariborz Jahanian <fjahanian at apple.com> 2010-11-02 16:35:37 CDT ---
Since report is about compiling this file and clang does not. We should keep
the report open
until other issues are investigated. clang issues errors like:


  m_k[i] = (word32)uk[4*i+3] | ((word32)uk[4*i+2]<<8) | ((word32)uk[4*i+1]<<16)
| ((word32)uk[4*i]<<24);
  ~~~^~
3way.cpp:71:6: note: built-in candidate operator[](unsigned int *, long)
3way.cpp:71:6: note: built-in candidate operator[](const unsigned int *, long)
3way.cpp:71:6: note: built-in candidate operator[](const void *, long)
3way.cpp:71:6: note: built-in candidate operator[](volatile unsigned int *,
long)
3way.cpp:71:6: note: built-in candidate operator[](void *, long)
3way.cpp:71:6: note: built-in candidate operator[](const restrict void *, long)
3way.cpp:71:6: note: built-in candidate operator[](const volatile void *, long)
3way.cpp:71:6: note: built-in candidate operator[](restrict void *, long)
3way.cpp:71:6: note: built-in candidate operator[](volatile void *, long)
3way.cpp:71:6: note: built-in candidate operator[](volatile restrict void *,
long)
3way.cpp:71:6: note: built-in candidate operator[](const volatile restrict void
*, long)
3way.cpp:71:6: note: built-in candidate operator[](const restrict unsigned int
*, long)
3way.cpp:71:6: note: built-in candidate operator[](const volatile unsigned int
*, long)
3way.cpp:71:6: note: built-in candidate operator[](restrict unsigned int *,
long)
3way.cpp:71:6: note: built-in candidate operator[](volatile restrict unsigned
int *, long)
3way.cpp:71:6: note: built-in candidate operator[](const volatile restrict
unsigned int *, long)

...

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

From bugzilla-daemon at llvm.org  Tue Nov  2 17:53:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 17:53:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8534] New: Typo in Testing Infrastructure Guide
Message-ID: <bug-8534-206@http.llvm.org/bugs/>

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

           Summary: Typo in Testing Infrastructure Guide
           Product: Website
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Trevor.W.Harmon at nasa.gov
                CC: llvmbugs at cs.uiuc.edu


"another name then" should be "another name than"

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

From bugzilla-daemon at llvm.org  Tue Nov  2 18:01:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 18:01:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8535] New: opt -O3 silently ignores
	-inline-threshold setting
Message-ID: <bug-8535-206@http.llvm.org/bugs/>

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

           Summary: opt -O3 silently ignores -inline-threshold setting
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: opt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


The -inline-threshold argument is quite confusing when running opt:

  "opt -O2" / "opt -O3" ignores it silently, and uses fixed values of 200 /
250.

  "opt -std-compile-opts" respects -inline-threshold.

I think that opt -O2 / -O3 should use the same default inlining threshold as
clang/llvm-gcc while still allowing the threshold to be overridden with
-inline-threshold.

Also, clang and llvm-gcc use 225 for -O2 and 275 for -O3 now.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 18:13:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 18:13:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8536] New: Assertion failed:
 (Value->getType()->isIntegerTy(1) && "value rep of bool not i1"),
 function EmitToMemory, file CGExpr.cpp, line 605.
Message-ID: <bug-8536-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (Value->getType()->isIntegerTy(1) &&
                    "value rep of bool not i1"), function EmitToMemory,
                    file CGExpr.cpp, line 605.
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stenorman2001 at me.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5720)
 --> (http://llvm.org/bugs/attachment.cgi?id=5720)
Configure log.

When compiling LLVM and Clang from the latest trunk (118107), an assertion
error occurs. The error is:

Assertion failed: (Value->getType()->isIntegerTy(1) && "value rep of bool not
i1"), function EmitToMemory, file CGExpr.cpp, line 605.

Attached is the output from configure and make.

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

From bugzilla-daemon at llvm.org  Tue Nov  2 18:22:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 18:22:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8537] New: Typos in Testing Infrastructure Guide
Message-ID: <bug-8537-206@http.llvm.org/bugs/>

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

           Summary: Typos in Testing Infrastructure Guide
           Product: Website
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Trevor.W.Harmon at nasa.gov
                CC: llvmbugs at cs.uiuc.edu


"not it's src" should be "not its src"

"lookas" should be "looks"

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

From bugzilla-daemon at llvm.org  Tue Nov  2 18:42:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 18:42:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8535] opt -O3 silently ignores -inline-threshold
	setting
In-Reply-To: <bug-8535-206@http.llvm.org/bugs/>
References: <bug-8535-206@http.llvm.org/bugs/>
Message-ID: <20101102234209.774752A6C12C@llvm.org>

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

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  Tue Nov  2 18:49:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 18:49:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8536] Assertion failed:
 (Value->getType()->isIntegerTy(1) && "value rep of bool not i1"),
 function EmitToMemory, file CGExpr.cpp, line 605.
In-Reply-To: <bug-8536-206@http.llvm.org/bugs/>
References: <bug-8536-206@http.llvm.org/bugs/>
Message-ID: <20101102234941.0FAD42A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-11-02 18:49:40 CDT ---
Please update the clang you're building with;  this has been fixed for a week.

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

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

From bugzilla-daemon at llvm.org  Tue Nov  2 19:30:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 19:30:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8537] Typos in Testing Infrastructure Guide
In-Reply-To: <bug-8537-206@http.llvm.org/bugs/>
References: <bug-8537-206@http.llvm.org/bugs/>
Message-ID: <20101103003037.EF3592A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-11-02 19:30:37 CDT ---
Applied in r118131, thanks!

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

From bugzilla-daemon at llvm.org  Tue Nov  2 20:09:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 20:09:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8012] clang c++ incorrectly accepts operator name
 as parameter name
In-Reply-To: <bug-8012-206@http.llvm.org/bugs/>
References: <bug-8012-206@http.llvm.org/bugs/>
Message-ID: <20101103010935.6234D2A6C124@llvm.org>

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

Sean Hunt <scshunt at csclub.uwaterloo.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |scshunt at csclub.uwaterloo.ca
         Resolution|                            |FIXED

--- Comment #1 from Sean Hunt <scshunt at csclub.uwaterloo.ca> 2010-11-02 20:09:35 CDT ---
Fixed in r118138

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

From bugzilla-daemon at llvm.org  Tue Nov  2 21:24:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 21:24:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3904] An incorrect asm statement causes an assert
	in clang.
In-Reply-To: <bug-3904-206@http.llvm.org/bugs/>
References: <bug-3904-206@http.llvm.org/bugs/>
Message-ID: <20101103022404.7C4142A6C12C@llvm.org>

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

Anders Carlsson <andersca at mac.com> changed:

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

--- Comment #3 from Anders Carlsson <andersca at mac.com> 2010-11-02 21:24:03 CDT ---
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20101101/036036.html

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

From bugzilla-daemon at llvm.org  Tue Nov  2 21:55:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  2 Nov 2010 21:55:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3905] An incorrect asm statement causes an assert
	in clang.
In-Reply-To: <bug-3905-206@http.llvm.org/bugs/>
References: <bug-3905-206@http.llvm.org/bugs/>
Message-ID: <20101103025513.B2E2F2A6C12C@llvm.org>

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

Anders Carlsson <andersca at mac.com> changed:

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

--- Comment #2 from Anders Carlsson <andersca at mac.com> 2010-11-02 21:55:13 CDT ---
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20101101/036037.html

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

From bugzilla-daemon at llvm.org  Wed Nov  3 03:05:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 03:05:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8511] likely x86 miscompile using clang
In-Reply-To: <bug-8511-206@http.llvm.org/bugs/>
References: <bug-8511-206@http.llvm.org/bugs/>
Message-ID: <20101103080537.4F37D2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2010-11-03 03:05:36 CDT ---
Maybe it was fixed by
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20101101/110916.html

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

From bugzilla-daemon at llvm.org  Wed Nov  3 03:17:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 03:17:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8534] Typo in Testing Infrastructure Guide
In-Reply-To: <bug-8534-206@http.llvm.org/bugs/>
References: <bug-8534-206@http.llvm.org/bugs/>
Message-ID: <20101103081720.6C7522A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2010-11-03 03:17:20 CDT ---
I updated the web page.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 04:18:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 04:18:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8538] New: clang with -O3 optimization level
 redefines functions from the included headers
Message-ID: <bug-8538-206@http.llvm.org/bugs/>

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

           Summary: clang with -O3 optimization level redefines functions
                    from the included headers
           Product: clang
           Version: 2.7
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: xinfinity_a at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Overview: 
Compile time errors "multiple definition of ... " for a number of functions
from the included headers (stdio.h, stdlib.h, math.h etc) , when compiling the
perlbench benchmark from SPEC CPU 2006 with clang -O3. In the LLVM IR [obtained
with -S -emit-llvm], the functions are already redefined in all the files *.ll
generated from the C source files in perlbench.

Steps to Reproduce:
1) Install SPEC CPU 2006
2) Use the attached config file (llvm.cfg) to build and run the benchmark: in
this file, clang is specified as the compiler in use and the optimization level
is O3
   runspec  --size test --tune base --noreportable --config llvm.cfg
400.perlbench

Actual Results: 
The benchmark cannot be compiled, the errors are in make.err file
I have tried also passing the option -std=  with c98, c99, gnu99 and I got the
same errors.

Expected Results: 
The application should successfully build and run. I tested the same benchmark
with optimization level O0 and it compiled and run correctly.

Build Date & Platform:
I have tested the released version 2.7.

I have installed LLVM and clang from sources with --enable-optimized and
--enable-assertions options.

I have a PC with Intel(R) Xeon(R) CPU on 64 bits and I am using Ubuntu 10.04
LTS - the Lucid Lynx. 

Additional Builds and Platforms: 
The bug appears in version 2.8 as well as in the version from the svn
repository: 29 Oct 2010 10:47AM. 

Additional Information: 
I attach the generated *.ll files: the ones generated with clang -O0 (which run
correctly) and the ones generated with -O3 (which contain multiple
definitions). Also the make.err file generated by the SPEC suite, containing
the errors, and the config file llvm.cfg I have used. I have changed only the
optimization level to obtain these two different sets of files.

The original files are available in SPEC CPU 2006 and the benchmark causing
problems is perlbench.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 08:35:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 08:35:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8539] New: clang++ chashes on invalid code.
Message-ID: <bug-8539-206@http.llvm.org/bugs/>

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

           Summary: clang++ chashes 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


Created an attachment (id=5725)
 --> (http://llvm.org/bugs/attachment.cgi?id=5725)
Invalid code resulting in a segfault.

The attached test (from gcc testsuite) causes a segmentation fault in clang
SemaOverload.cpp:2731.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 09:40:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 09:40:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8540] New: "llvm-gcc -m96bit-long-double" addresses
 memory incorrectly
Message-ID: <bug-8540-206@http.llvm.org/bugs/>

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

           Summary: "llvm-gcc -m96bit-long-double" addresses memory
                    incorrectly
           Product: new-bugs
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jdenny at etinternational.com
                CC: llvmbugs at cs.uiuc.edu


My platform is x86-64, so llvm-gcc normally folds sizeof(long double) into 16. 
The problem is that "llvm-gcc -m96bit-long-double" folds sizeof(long double)
into 12, but getelementptr still assumes 16.

This problem can be demonstrated as follows:

% cat > test.c
#include <stdio.h>
#include <stdlib.h>
#define SIZE 5
int
main(void)
{
  long double *a = malloc(sizeof(long double) * SIZE);
  for (int i = 0; i < SIZE; ++i)
    a[i] = i+1;
  for (int i = 0; i < SIZE; ++i)
    printf ("a[%d] = %Lf\n", i, a[i]);
  free (a);
  return 0;
}
% llvm-gcc -std=c99 -m96bit-long-double -emit-llvm -S -o test.ll test.c
% llvmc test.ll
% valgrind ./a.out |& grep Invalid
==3882== Invalid write of size 4
==3882== Invalid write of size 2
==3882== Invalid read of size 4
==3882== Invalid read of size 2

Looking inside test.ll, I see f80:128:128, but I also see sizeof(long 
double)*5 folded into 60.  Changing f80:128:128 to f80:96:96 does not fix 
the errors reported by valgrind.  If I instead fix the folded constant, 
the errors go away, of course.

Further discussion appears in this thread:

  http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/035936.html

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

From bugzilla-daemon at llvm.org  Wed Nov  3 10:12:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 10:12:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8541] New: Clang miscompiles libgcc's unwind-dw2.c
Message-ID: <bug-8541-206@http.llvm.org/bugs/>

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

           Summary: Clang miscompiles libgcc's unwind-dw2.c
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ed at 80386.nl
                CC: llvmbugs at cs.uiuc.edu


FreeBSD HEAD is currently shipped with this version of clang:

$ clang --version
FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007

In this thread, it is reported that OpenOffice crashes when libgcc_s.so.1 is
built with this version of Clang:

http://lists.freebsd.org/pipermail/freebsd-current/2010-November/020843.html

It turns out that this is due to some kind of miscompilation of unwind-dw2.c.
This is our version of unwind-dw2.c:

http://svn.freebsd.org/viewvc/base/head/contrib/gcc/unwind-dw2.c?view=markup

Although I realize this bug report may be too incomplete to be useful, but I'd
rather stick it here in Bugzilla to prevent it from getting lost.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 12:00:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 12:00:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8477] "overloaded operator '[]' is ambiguous" error,
 probably false
In-Reply-To: <bug-8477-206@http.llvm.org/bugs/>
References: <bug-8477-206@http.llvm.org/bugs/>
Message-ID: <20101103170059.5BA092A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-03 12:00:58 CDT ---
Fixed in Clang r118178.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 12:53:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 12:53:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7702] unclear diagnostic after 'new'
In-Reply-To: <bug-7702-206@http.llvm.org/bugs/>
References: <bug-7702-206@http.llvm.org/bugs/>
Message-ID: <20101103175328.1BD782A6C12E@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #2 from Nick Lewycky <nlewycky at google.com> 2010-11-03 12:53:27 CDT ---
Fixed in r118181. If the error isn't quite good enough, we can iterate on it
further.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 13:07:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 13:07:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8530] Clang rejects enum comparison operators
In-Reply-To: <bug-8530-206@http.llvm.org/bugs/>
References: <bug-8530-206@http.llvm.org/bugs/>
Message-ID: <20101103180705.AC0502A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-03 13:07:05 CDT ---
This is already fixed in 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  Wed Nov  3 16:03:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 16:03:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8542] New: Clang miscompiles valid code with -O2 on
 x86 and x86-64
Message-ID: <bug-8542-206@http.llvm.org/bugs/>

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

           Summary: Clang miscompiles valid code with -O2 on x86 and
                    x86-64
           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: lloyd at randombit.net
                CC: llvmbugs at cs.uiuc.edu


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

Attached is a simple test case which clang 2.8 miscompiles on x86 and x86-64
with -O2 or higher (I have not traced down the specific optimization flag which
causes the problem). With GCC or ICC (any optimization level) or Clang 2.8 with
-O0 or -O1, the output is

61000000

with Clang and -O2/-O3, it is:

F9000000

I've tried to minimize the test case as much as possible; it was extracted from
real code.

Interestingly, changing
   W &= rotate_right(0x00FFFFFF, 0);
to just
   W &= 0x00FFFFFFF;

on line 36

the miscompilation goes away (actually removing this rotation is is not
possible in the original source, which runs this in a loop with varying byte
offsets).

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

From bugzilla-daemon at llvm.org  Wed Nov  3 17:07:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 17:07:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8542] Clang miscompiles valid code with -O2 on x86
	and x86-64
In-Reply-To: <bug-8542-206@http.llvm.org/bugs/>
References: <bug-8542-206@http.llvm.org/bugs/>
Message-ID: <20101103220712.2AF162A6C124@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2010-11-03 17:07:11 CDT ---
The original code is invalid:

unsigned int rotate_right(unsigned int input, unsigned int rot)
   {
   return ((input >> rot) | (input << (32-rot)));
   }

When rot = 0, 32-rot = 32 and this performs "input << 32" which has undefined
behaviour and can produce any value we want to, even different numbers each
time.

The real code is buggy and needs to be fixed.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 17:55:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 17:55:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8543] Wrong cast kind for a const char* -> char*
	cast.
In-Reply-To: <bug-8543-206@http.llvm.org/bugs/>
References: <bug-8543-206@http.llvm.org/bugs/>
Message-ID: <20101103225532.E37D42A6C130@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dgregor at apple.com,
                   |                            |llvmbugs at cs.uiuc.edu
          Component|Frontend                    |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 Nov  3 19:10:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 19:10:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8182] wrong constructor choice (templates)
In-Reply-To: <bug-8182-206@http.llvm.org/bugs/>
References: <bug-8182-206@http.llvm.org/bugs/>
Message-ID: <20101104001004.821412A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-11-03 19:10:04 CDT ---
Fixed in Clang r118211.

Fun 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 Nov  3 19:10:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 19:10:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8182] wrong constructor choice (templates)
In-Reply-To: <bug-8182-206@http.llvm.org/bugs/>
References: <bug-8182-206@http.llvm.org/bugs/>
Message-ID: <20101104001025.D26802A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2010-11-03 19:10:25 CDT ---
Oops, nevermind! Closed the wrong bug... this one is *not* fixed.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 19:11:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 19:11:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7419] Fail to recognize that return types match
 through two typedefs
In-Reply-To: <bug-7419-206@http.llvm.org/bugs/>
References: <bug-7419-206@http.llvm.org/bugs/>
Message-ID: <20101104001106.3B5A82A6C130@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-03 19:11:05 CDT ---
Fun bug! Fixed in Clang r118211.

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

From bugzilla-daemon at llvm.org  Wed Nov  3 21:49:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  3 Nov 2010 21:49:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8544] New: -Wold-style-definition has no effect
Message-ID: <bug-8544-206@http.llvm.org/bugs/>

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

           Summary: -Wold-style-definition has no effect
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jpbonn-keyword-llvmbug.a51747 at corniceresearch.com
                CC: llvmbugs at cs.uiuc.edu


When the following program is compiled using GCC with -Wold-style-definition it
warns about the definition of f(). Clang does not issue a warning for f().

This example was distilled from the GCC teststuite:

typedef struct {
  long int p_x, p_y;
} Point;

void
f (p0, p1)
     Point p0, p1;
{
  if (p0.p_x != 0)
    abort ();
}

int
main ()
{
  Point p0, p1;
  p0.p_x = p1.p_x = 0;
  p0.p_y = p1.p_y = 1;
  f (p0, p1);
  exit(0);
}

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

From bugzilla-daemon at llvm.org  Thu Nov  4 00:43:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Nov 2010 00:43:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8545] New: X.org 1.7.5 doesn't run,
 undefined symbols in extensions
Message-ID: <bug-8545-206@http.llvm.org/bugs/>

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

           Summary: X.org 1.7.5 doesn't run, undefined symbols in
                    extensions
           Product: clang
           Version: 2.8
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chromium at hybridsource.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5735)
 --> (http://llvm.org/bugs/attachment.cgi?id=5735)
xorg extension errors

I'm able to compile the X.org server with clang 2.8 and svn-r118232 but it
won't run because of undefined symbols in extension modules.  The exact same
source compiles and runs fine with gcc 4.2, I've attached a diff of the two
Xorg.log files showing what happens in failure vs success.  I notice that when
I compile with clang ToT, I get several warnings saying

clang: warning: argument unused during compilation: '-fvisibility=hidden'

but I don't see those same warnings with clang 2.8.  In any case, X.org
compiled with both clang versions fails to run with the same undefined symbol
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 Nov  4 00:51:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Nov 2010 00:51:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8546] New: CMake/MSVS: Don't be bothered with
 dialogs of updating project files on Visual Studio
Message-ID: <bug-8546-206@http.llvm.org/bugs/>

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

           Summary: CMake/MSVS: Don't be bothered with dialogs of updating
                    project files on Visual Studio
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu


ZERO_CHECK easily updates project files, and sometimes we will meet hundreds of
dialogs notification. (click click click... or terminate devenv.exe with
taskmgr.exe)

By touching (or regenerating together) LLVM.sln, it might be bypassed.

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

From bugzilla-daemon at llvm.org  Thu Nov  4 03:49:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Nov 2010 03:49:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7896] c++ crash with overloading and using decl in
 class template
In-Reply-To: <bug-7896-206@http.llvm.org/bugs/>
References: <bug-7896-206@http.llvm.org/bugs/>
Message-ID: <20101104084918.BD5AF2A6C12E@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #1 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2010-11-04 03:49:18 CDT ---
Fixed at r118239.

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

From bugzilla-daemon at llvm.org  Thu Nov  4 09:07:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Nov 2010 09:07:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8547] New: likely x86 miscompile using clang
Message-ID: <bug-8547-206@http.llvm.org/bugs/>

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

           Summary: likely x86 miscompile using clang
           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


The -O1 result looks wrong.

regehr at home:~$ clang -O0 foo.c -o foo
regehr at home:~$ ./foo
g_2 = 64
regehr at home:~$ clang -O1 foo.c -o foo
regehr at home:~$ ./foo
g_2 = 320
regehr at home:~$ cat foo.c
int g_2;

int printf(const char *format, ...);

int main(void) {
  for (g_2 = 0; g_2 > -1; g_2++)
    {
      g_2 = (char)(g_2 << 6);
      if (g_2)
    break;
      g_2 = 4;
    }
  printf("g_2 = %d\n", g_2);
  return 0;
} 
regehr at home:~$ clang -v
clang version 2.9 (trunk 118140)
Target: i386-pc-linux-gnu
Thread model: posix

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

From bugzilla-daemon at llvm.org  Thu Nov  4 10:26:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Nov 2010 10:26:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8548] New: Patch: Support for unregistering
 exception frames of functions when they are removed
Message-ID: <bug-8548-206@http.llvm.org/bugs/>

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

           Summary: Patch: Support for unregistering exception frames of
                    functions when they are removed
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Target-Independent JIT
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: schaub-johannes at web.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5736)
 --> (http://llvm.org/bugs/attachment.cgi?id=5736)
The patch implementing it.

http://llvm.org/bugs/show_bug.cgi?id=8285 implemented unregistering of
exception frames upon destruction of the JIT. 

This one enhances that by allowing the JIT to unregister the frames also when a
function's machine code is free'ed.

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

From bugzilla-daemon at llvm.org  Thu Nov  4 14:05:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Nov 2010 14:05:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8129] clang++ not suppressing warnings in standard
	headers.
In-Reply-To: <bug-8129-206@http.llvm.org/bugs/>
References: <bug-8129-206@http.llvm.org/bugs/>
Message-ID: <20101104190510.7FB9A2A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-11-04 14:05:09 CDT ---
Fixed in r118258.

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

From bugzilla-daemon at llvm.org  Thu Nov  4 16:17:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  4 Nov 2010 16:17:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7170] llc infinite loop in getMemcpyLoadsAndStores
In-Reply-To: <bug-7170-206@http.llvm.org/bugs/>
References: <bug-7170-206@http.llvm.org/bugs/>
Message-ID: <20101104211746.ABCC02A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2010-11-04 16:17:45 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20101101/111138.html

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

From bugzilla-daemon at llvm.org  Fri Nov  5 00:10:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 00:10:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8538] clang with -O3 optimization level redefines
 functions from the included headers
In-Reply-To: <bug-8538-206@http.llvm.org/bugs/>
References: <bug-8538-206@http.llvm.org/bugs/>
Message-ID: <20101105051009.7FB1A2A6C12E@llvm.org>

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

Dale Johannesen <dalej at apple.com> changed:

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

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

From bugzilla-daemon at llvm.org  Fri Nov  5 08:26:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 08:26:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8550] New: Spurious conversion error ?
Message-ID: <bug-8550-206@http.llvm.org/bugs/>

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

           Summary: Spurious conversion error ?
           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


$ cat bug.C
struct Z {};

Z* foo(Z*);

struct B : Z
{
  static const int i = sizeof( foo((B*) 0) );
};


$ clang++ -cc1 bug.C
bug.C:7:32: error: no matching function for call to 'foo'
  static const int i = sizeof( foo((B*) 0) );
                               ^~~
bug.C:3:4: note: candidate function not viable: cannot convert argument of
incomplete type 'B *' to 'Z *'
Z* foo(Z*);
   ^
1 error generated.


The test is compiled by both gcc and Comeau.

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

From bugzilla-daemon at llvm.org  Fri Nov  5 08:47:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 08:47:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8551] New: Wrong type for address-of anonymous
	union member.
Message-ID: <bug-8551-206@http.llvm.org/bugs/>

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

           Summary: Wrong type for address-of anonymous union member.
           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


clang++ generates an error diagnostic when parsing the following program (from
g++ testsuite):

struct myclass {
  unsigned a;
  union {
    unsigned x;
  };
};

int main () {
  myclass foo;
  unsigned myclass::* member = &myclass::x;
  if (&(foo.*member) != &foo.x)
    return 1;
}


$ clang++ -cc1 bug.C
bug.C:13:23: error: cannot initialize a variable of type 'unsigned int
myclass::*' with an rvalue of type 'unsigned int myclass::<anonymous union at
bug.C:6:3>::*'
  unsigned myclass::* member = &myclass::x;
                      ^        ~~~~~~~~~~~
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 Nov  5 10:01:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 10:01:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8552] New: Code Generator Discards ILP Impacting
 Floating-point throughput
Message-ID: <bug-8552-206@http.llvm.org/bugs/>

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

           Summary: Code Generator Discards ILP Impacting Floating-point
                    throughput
           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: arkerr at gatech.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5740)
 --> (http://llvm.org/bugs/attachment.cgi?id=5740)
Microbenchmark revealing performance bug

I.

I've noticed an unusual behavior of the LLVM x86 code generator (with default
options) that results in nearly a 4x slow-down in floating-point throughput for
my microbenchmark. We've noticed less than expected in other benchmarks and
feel this could have a reasonable impact on many applications.

I've written a compute-intensive microbenchmark to approach theoretical peak
throughput of the target processor by issuing a large number of independent
floating-point multiplies. The distance between dependent instructions is at
least four instructions to match the latency of the floating-point functional
unit in my Intel Core2 Quad (Q9550 at 2.83 GHz).

II.

The attached microbenchmark can be built with both gcc and clang using the
following command. This prints performance results for several problem sizes.
On my Intel Q9550, I see

$ make run

gcc
# blocks   GFLOPs/second
1          5.648591
2          5.650618
3          5.650704
4          5.649433

llvm
# blocks   GFLOPs/second
1          0.857245
2          0.857162
3          0.857154
4          0.857187
$


Additionally, assembly files are produced by both compilers which reveal the
problem in code scheduling.

III.

The microbenchmark itself replicates the following block 512 times:

 .
 .
 {
  p1 = p1 * a;
  p2 = p2 * b;
  p3 = p3 * c;
  p4 = p4 * d;
 }
 .
 .

Compiling with NVCC, Ocelot, and LLVM, I can confirm the interleaved
instruction schedule with a four-instruction reuse distance. An excerpt
follows:

  .
  .
  %r1500 = fmul float %r1496, %r24  ; compute %1500
  %r1501 = fmul float %r1497, %r23
  %r1502 = fmul float %r1498, %r22
  %r1503 = fmul float %r1499, %r21

  %r1504 = fmul float %r1500, %r24  ; first use of %1500
  %r1505 = fmul float %r1501, %r23
  %r1506 = fmul float %r1502, %r22
  %r1507 = fmul float %r1503, %r21

  %r1508 = fmul float %r1504, %r24  ; first use of %1504
  .
  .

The JIT compiler, however, seems to break the interleaving of independent
instructions and issues a long sequence of instructions with back-to-back
dependencies. It is as if all p1 = .. expressions are collected at once
followed by all p2 = .. expressions and so forth.

 p1 = p1 * a
 p1 = p1 * a
 .
 .

 p2 = p2 * b
 p2 = p2 * b
 .
 .

 p3 = p3 * c
 p3 = p3 * c
 .
 .

An actual excerpt of the generated x86 assembly follows:

  mulss        %xmm8, %xmm10
  mulss        %xmm8, %xmm10
  .
  . repeated 512 times
  .

  mulss        %xmm7, %xmm9
  mulss        %xmm7, %xmm9
  .
  . repeated 512 times
  .

  mulss        %xmm6, %xmm3
  mulss        %xmm6, %xmm3
  .
  . repeated 512 times
  .

Since p1, p2, p3, and p4 are all independent, this reordering is correct. This
would have the possible advantage of reducing live ranges of values. However,
in this microbenchmark, the number of live values is eight single-precision
floats - well within SSE's sixteen architectural registers.

Moreover, the pipeline latency is four cycles meaning back-to-back instructions
with true dependencies cannot issue immediately. The benchmark was
intentionally written to avoid this hazard but LLVM's code generator seems to
ignore that when it schedules instructions.

When I run this benchmark on my 2.83 GHz CPU, I observe the following
performance results:

  1 threads       0.648891 GFLOP/s
  2 threads       1.489049 GFLOP/s
  3 threads       2.209838 GFLOP/s
  4 threads       2.940443 GFLOP/s

When I rewrite the generated assembly by hand to exhibit the same interleaving
as in the
LLVM IR form

  .
  .
  mulss        %xmm8, %xmm10
  mulss        %xmm7, %xmm9
  mulss        %xmm6, %xmm3
  mulss        %xmm5, %xmm11

  mulss        %xmm8, %xmm10
  mulss        %xmm7, %xmm9
  mulss        %xmm6, %xmm3
  mulss        %xmm5, %xmm11

  mulss        %xmm8, %xmm10
  mulss        %xmm7, %xmm9
  .
  .

observed performance increases by nearly a factor of four:

  1 threads       2.067118 GFLOP/s
  2 threads       5.569419 GFLOP/s
  3 threads       8.285519 GFLOP/s
  4 threads       10.81742 GFLOP/s

I show similar results with packed single-precision floating point SIMD
instructions. The LLVM-generated machine code is nearly 4x slower than the
interleaved schedule 'suggested' by the LLVM IR input.

  Vectorized - No instruction interleaving - back-to-back dependencies
    (issued by LLVM code generator)

  1 threads        1.540621 GFLOP/s
  2 threads        5.900833 GFLOP/s
  3 threads        8.755953 GFLOP/s
  4 threads        11.257122 GFLOP/s

  Vectorized - Interleaved - stride-4 reuse distance
    (hand-modified to interleave instructions)

  1 threads       3.157255 GFLOP/s
  2 threads       22.104369 GFLOP/s
  3 threads       32.300111 GFLOP/s
  4 threads       39.112162 GFLOP/s

It is worth noting that 39.1 GFLOP/s is approaching the theoretical limits of
the processor (stated to be 45.25 GFLOP/s single-precision).

I've used the llc utility to test various pre-register-allocation instruction
schedulers with the following results:

  -pre-RA-sched
    =default         - discards ILP
    =list-burr       - discards ILP
    =list-tdrr       - crashes during code generation

    =source          - preserves interleaved instruction ordering and ILP

    =list-hybrid     - discards ILP
    =list-ilp        - discards ILP
    =list-td         - crashes during code generation
    =fast            - discards ILP

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

From bugzilla-daemon at llvm.org  Fri Nov  5 11:54:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 11:54:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8553] New: False positive "garbage data"
Message-ID: <bug-8553-206@http.llvm.org/bugs/>

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

           Summary: False positive "garbage data"
           Product: clang
           Version: 2.7
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: ldm5180+clang at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The attached code causes "new_value" to be marked as garbage data, but it is
not. It has been set through the pointer "dest".

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

From bugzilla-daemon at llvm.org  Fri Nov  5 12:26:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 12:26:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8554] New: clang fails GCC test 20020614.c: illegal
 simplifications when folding constants
Message-ID: <bug-8554-206@http.llvm.org/bugs/>

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

           Summary: clang fails GCC test 20020614.c: illegal
                    simplifications when folding constants
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jpbonn-keyword-llvmbug.a51747 at corniceresearch.com
                CC: llvmbugs at cs.uiuc.edu


This test fails with clang v118276 on Intel OSX (and probably others).  I
haven't looked at it at all. It's from the GCC testsuite:
gcc.c-torture/execute/20020614.c

/* PR c/6677 */
/* Verify that GCC doesn't perform illegal simplifications
   when folding constants.  */

#include <limits.h>

extern void abort (void);
extern void exit (int);

int main (void)
{
  int i;
  signed char j;
  unsigned char k;

  i = SCHAR_MAX;

  j = ((signed char) (i << 1)) / 2;

  if (j != -1)
    abort();

  j = ((signed char) (i * 2)) / 2;

  if (j != -1)
    abort();

  i = UCHAR_MAX;

  k = ((unsigned char) (i << 1)) / 2;

  if (k != UCHAR_MAX/2)
    abort();

  k = ((unsigned char) (i * 2)) / 2;

  if (k != UCHAR_MAX/2)
    abort();

  exit(0);
}

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

From bugzilla-daemon at llvm.org  Fri Nov  5 14:37:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 14:37:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8556] New: error: invalid instruction mnemonic
	'xcrypt'
Message-ID: <bug-8556-206@http.llvm.org/bugs/>

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

           Summary: error: invalid instruction mnemonic 'xcrypt'
           Product: new-bugs
           Version: trunk
          Platform: Sun
        OS/Version: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: amitkulz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


/usr/src/lib/libssl/crypto/../src/crypto/engine/hw_cryptodev.c:635:19: error:
invalid instruction mnemonic 'xcrypt'
        __asm __volatile("rep xcrypt-cbc" :
                         ^
<inline asm>:1:6: note: instantiated into assembly here
        rep xcrypt-cbc
            ^


This happens while compiling OpenBSD -current userland code. Googling brings me
to http://www.openbsd.org/plus35.html which mentions

Add as(1) support for the VIA C3 xmove-rng and xcrypt-{ecb,cbc,cfb,ofb}
instructions.

So LLVM backend needs to add support for 'as' for VIA instructions.

Thanks

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

From bugzilla-daemon at llvm.org  Fri Nov  5 18:25:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 18:25:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8234] Assertion when instantiating template
In-Reply-To: <bug-8234-206@http.llvm.org/bugs/>
References: <bug-8234-206@http.llvm.org/bugs/>
Message-ID: <20101105232558.8EA712A6C130@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #1 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2010-11-05 18:25:57 CDT ---
Fixed at r118314.

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

From bugzilla-daemon at llvm.org  Fri Nov  5 18:58:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  5 Nov 2010 18:58:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8557] New: Clang crashes when trying to compile a
 file with properties
Message-ID: <bug-8557-206@http.llvm.org/bugs/>

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

           Summary: Clang crashes when trying to compile a file with
                    properties
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: js-llvm-bugzilla at webkeks.org
                CC: llvmbugs at cs.uiuc.edu


assertion "(i
 >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) &&
"Cal
ling a function with a bad signature!"" failed: file "Instructions.cpp", line
24
6, function "void llvm::CallInst::init(llvm::Value*, llvm::Value* const*,
unsign
ed int)"
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-netb
sd5.1. -S -disable-free -main-file-name PropertiesTests.m -mrelocation-model
sta
tic -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64
-
target-linker-version 2.16.1 -g -resource-dir /usr/local/bin/../lib/clang/2.9
-D
 STDOUT -I ../src -I .. -O2 -Wall -Werror -fconstant-string-class
OFConstantStri
ng -ferror-limit 19 -fmessage-length 0 -fblocks -fexceptions -fgnu-runtime
-fno-
constant-cfstrings -fno-common -fdiagnostics-show-option -o /tmp/cc-14497a.s -x 
objective-c PropertiesTests.m 
1.      PropertiesTests.m:44:1: current parser token '@'
2.      PropertiesTests.m:31:1: LLVM IR generation of declaration
'PropertiesTes
t'
clang: error: unable to execute command: Abort trap (core dumped)
clang: error: clang frontend command failed due to signal 1 (use -v to see
invoc
ation)

The file is: http://sprunge.us/KFLU

All other files that are similar tests, but don't contain properties, 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  Sat Nov  6 02:38:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Nov 2010 02:38:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8559] New: clang -arch armv6 can't load immediates
 into registers
Message-ID: <bug-8559-206@http.llvm.org/bugs/>

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

           Summary: clang -arch armv6 can't load immediates into registers
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rjmccall at apple.com
                CC: llvmbugs at cs.uiuc.edu


daysthatwere:clang rjmccall$ clang -v
clang version 2.9 (trunk 118329)
Target: x86_64-apple-darwin10
Thread model: posix
daysthatwere:clang rjmccall$ cat /tmp/red.m
@interface NSObject
+ (id) alloc;
@end

void bar(void);

void foo(id i) {
  @synchronized (i) {
    bar();
  }
}

int main() {
  @try {
    foo([NSObject alloc]);
  } @catch (id e) {
  }
}
daysthatwere:clang rjmccall$ clang -arch armv6 /tmp/red.m
/var/folders/s9/s96FsWmjFfOmejEGjQKJMU+++TI/-Tmp-/cc-evXTDd.s:34:selected
processor does not support `movw r1,#0'
/var/folders/s9/s96FsWmjFfOmejEGjQKJMU+++TI/-Tmp-/cc-evXTDd.s:200:selected
processor does not support `movw r0,#0'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
daysthatwere:clang rjmccall$

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

From bugzilla-daemon at llvm.org  Sat Nov  6 02:54:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Nov 2010 02:54:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8559] clang -arch armv6 can't load immediates into
	registers
In-Reply-To: <bug-8559-206@http.llvm.org/bugs/>
References: <bug-8559-206@http.llvm.org/bugs/>
Message-ID: <20101106075402.C643C2A6C134@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #1 from Eric Christopher <echristo at gmail.com> 2010-11-06 02:54:02 CDT ---
Fixed thusly:


[issola:lib/Target/ARM] echristo% svn ci
Sending        ARM/ARMFastISel.cpp
Transmitting file data .
Committed revision 118333.


[issola:~] echristo% ~/builds/build-llvm/Debug+Asserts/bin/clang -arch armv6 -S
foo.m
[issola:~] echristo% grep movw foo.s
[issola:~] echristo%

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

From bugzilla-daemon at llvm.org  Sat Nov  6 09:05:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Nov 2010 09:05:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8560] New: Uninitialised memory access issue with
 llvm::PHINode::reserveOperandSpace
Message-ID: <bug-8560-206@http.llvm.org/bugs/>

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

           Summary: Uninitialised memory access issue with
                    llvm::PHINode::reserveOperandSpace
           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: bnwest at rice.edu
                CC: llvmbugs at cs.uiuc.edu


I am developing a new optimization pass.  I am experiencing some erratic
execution problems, so I decided to 'memcheck' the opt built with my -osr
optimization.  The results suggest that there is an 'uninitialised value'
access.  To be precise the error is "Conditional jump or move depends on
uninitialised value(s)".

This is the sequence of my code that cause the problem:

    PHINode *phinode;
    phinode = PHINode::Create(optype, Twine(), IV);
    phinode->reserveOperandSpace(NumOperands/2);

As of revision 117932 ...


/usr/local/bin/valgrind --leak-check=yes opt sort.ssa.ll -S -o sort.osr.ll
-stats -osr

==71994== Memcheck, a memory error detector
==71994== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==71994== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==71994== Command: opt sort.ssa.ll -S -o sort.osr.ll -stats -osr
==71994== 
--71994-- /Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt:
--71994-- dSYM directory is missing; consider using --dsymutil=yes
==71994== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==71994==          the SIGUSR2 signal is used internally by Valgrind
==71994== Conditional jump or move depends on uninitialised value(s)
==71994==    at 0x1003E71B1: llvm::PHINode::resizeOperands(unsigned int) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x1001B4DC1: llvm::PHINode::reserveOperandSpace(unsigned int)
(in /Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x1001206DB: (anonymous
namespace)::OperatorStrengthReduction::Reduce(llvm::Instruction*, unsigned int,
llvm::Type const*, llvm::Value*) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x100122535: (anonymous
namespace)::OperatorStrengthReduction::Replace(llvm::Instruction*,
llvm::Instruction*, llvm::Value*) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x100122D1C: (anonymous
namespace)::OperatorStrengthReduction::ProcessSCC(std::vector<llvm::Instruction*,
std::allocator<llvm::Instruction*> >) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x1001231D8: (anonymous
namespace)::OperatorStrengthReduction::DFS(llvm::Instruction*) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x10012334C: (anonymous
namespace)::OperatorStrengthReduction::OSR(llvm::Function&) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x1001234BB: (anonymous
namespace)::OperatorStrengthReduction::runOnFunction(llvm::Function&) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x100411969:
llvm::FPPassManager::runOnFunction(llvm::Function&) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x100411B3C: llvm::FPPassManager::runOnModule(llvm::Module&)
(in /Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x100411639: llvm::MPPassManager::runOnModule(llvm::Module&)
(in /Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)
==71994==    by 0x100412DEA: llvm::PassManagerImpl::run(llvm::Module&) (in
/Users/bnwest/PACE/LLVM/llvm/build/Debug+Asserts/bin/opt)

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

From bugzilla-daemon at llvm.org  Sat Nov  6 10:50:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Nov 2010 10:50:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8560] Uninitialised memory access issue with
 llvm::PHINode::reserveOperandSpace
In-Reply-To: <bug-8560-206@http.llvm.org/bugs/>
References: <bug-8560-206@http.llvm.org/bugs/>
Message-ID: <20101106155014.03BD52A6C133@llvm.org>

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

Brian West <bnwest at rice.edu> changed:

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

--- Comment #3 from Brian West <bnwest at rice.edu> 2010-11-06 10:50:13 CDT ---
This is my problem :(. The argument to llvm::PHINode::reserveOperandSpace() in
my code sometimes was not initialized.

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

From bugzilla-daemon at llvm.org  Sat Nov  6 13:30:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Nov 2010 13:30:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8528] [MC X86] dct64_sse.c from MPlayer is
	miscompiled
In-Reply-To: <bug-8528-206@http.llvm.org/bugs/>
References: <bug-8528-206@http.llvm.org/bugs/>
Message-ID: <20101106183001.F25F32A6C136@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #14 from Chris Lattner <clattner at apple.com> 2010-11-06 13:30:01 CDT ---
This is fixed in r118346, we now reject the invalid instructions with:

t.s:1:1: error: ambiguous instructions require an explicit suffix (could be
'fstps', 'fstpl', or 'fstpt')
fstp    (%rax)
^
t.s:2:1: error: ambiguous instructions require an explicit suffix (could be
'fistps', or 'fistpl')
fistp (%rax)
^
t.s:3:1: error: ambiguous instructions require an explicit suffix (could be
'fists', or 'fistl')
fist (%rax)
^

Thanks again for tracking this down!

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

From bugzilla-daemon at llvm.org  Sat Nov  6 19:42:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Nov 2010 19:42:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8418] X86 assembler doesn't support div
 instructions with explicit A register
In-Reply-To: <bug-8418-206@http.llvm.org/bugs/>
References: <bug-8418-206@http.llvm.org/bugs/>
Message-ID: <20101107004246.4A2A52A6C136@llvm.org>

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

Charles Davis <cdavis at mymail.mines.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
            Summary|X86 assembler can't infer   |X86 assembler doesn't
                   |size suffixes on certain    |support div instructions
                   |instructions                |with explicit A register

--- Comment #1 from Charles Davis <cdavis at mymail.mines.edu> 2010-11-06 19:42:45 CDT ---
I'm sorry, I didn't know LLVM didn't even support div instructions with the
implicit accumulator operand specified explicitly. Anyway, r118364 fixes this.

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

From bugzilla-daemon at llvm.org  Sat Nov  6 22:30:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  6 Nov 2010 22:30:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8561] New: LLVM miscompiles a function from Wine
Message-ID: <bug-8561-206@http.llvm.org/bugs/>

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

           Summary: LLVM miscompiles a function from Wine
           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: cdavis at mymail.mines.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5742)
 --> (http://llvm.org/bugs/attachment.cgi?id=5742)
LLVM IR of miscompiled function from Wine

Now that PR8418 is fixed (thanks, Chris!), I took a stab at building Wine with
Clang at -O2. It builds successfully, but unfortunately, the resulting Wine
segfaults on start-up. This happens before Wine installs its own signal
handlers, so the OS picks it up and produces a backtrace. The backtrace pointed
to the "reserve_area" function.

I've isolated this function and compiled it to LLVM IR. I don't know where or
why this is happening, but this is preventing Wine from being usable when
compiled at -O2.

>From looking at the source, this function is a recursive function, so that
could have something to do with it.

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

From bugzilla-daemon at llvm.org  Sun Nov  7 00:40:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Nov 2010 00:40:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8563] New: clang hangs while optimizing a snippet
	of C++ code
Message-ID: <bug-8563-206@http.llvm.org/bugs/>

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

           Summary: clang hangs while optimizing a snippet of C++ code
           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


At least that is what it looks like.

  Compiling the file in question with g++ 4.4:

pipping at bogus ~ $ time g++ -w -c foo.cpp 

real    0m16.027s
user    0m15.492s
sys     0m0.520s
pipping at bogus ~ $ 

  Compiling it with clang++ (I aborted after a couple of minutes):

pipping at bogus ~ $ time clang++ -w -c foo.cpp 
^C

real    4m26.475s
user    0m0.019s
sys     0m0.010s
pipping at bogus ~ $ 

  What confuses me is this:

pipping at bogus ~ $ time clang++ -w -c foo.cpp -o foo.bc -emit-llvm

real    0m4.783s
user    0m4.581s
sys     0m0.198s
pipping at bogus ~ $ time llc foo.bc -o foo.o

real    0m22.721s
user    0m22.443s
sys     0m0.264s
pipping at bogus ~ $ 


Shouldn't one of the former two hang as well?

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

From bugzilla-daemon at llvm.org  Sun Nov  7 09:05:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Nov 2010 09:05:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 8563] clang hangs while running the integrated
 assembler for a snippet of C++ code
In-Reply-To: <bug-8563-206@http.llvm.org/bugs/>
References: <bug-8563-206@http.llvm.org/bugs/>
Message-ID: <20101107150517.C0A8C2A6C12E@llvm.org>

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

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

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

--- Comment #6 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-07 09:05:17 CST ---
Fixed in 118377.

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

From bugzilla-daemon at llvm.org  Sun Nov  7 15:51:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Nov 2010 15:51:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 8564] New: On Mac OS libLLVM-2.9svn.dylib is linked
 to be used by tools only
Message-ID: <bug-8564-206@http.llvm.org/bugs/>

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

           Summary: On Mac OS libLLVM-2.9svn.dylib is linked to be used by
                    tools only
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jerrry94087 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


I configured llvm with --prefix=/opt/local/llvm
But dylib is linked with -Wl,"@executable_path/../lib/libLLVM-2.9svn.dylib"
And the way how things are on Mac OS gcc option -L/opt/local/llvm/lib doesn't
override this path @executable_path/../lib/libLLVM-2.9svn.dylib encoded into
the library itself. So the resulting libLLVM-2.9svn.dylib is only usable by
LLVM tools from under /opt/local/llvm. Other executables linked against it fail
to find @executable_path/../lib/libLLVM-2.9svn.dylib.

Linker command should be modified: @executable_path/../lib/libLLVM-2.9svn.dylib
should be replaced with <path-from-configured-prefix>/lib/libLLVM-2.9svn.dylib

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

From bugzilla-daemon at llvm.org  Sun Nov  7 16:59:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Nov 2010 16:59:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 8545] X.org 1.7.5 doesn't run,
	undefined symbols in extensions
In-Reply-To: <bug-8545-206@http.llvm.org/bugs/>
References: <bug-8545-206@http.llvm.org/bugs/>
Message-ID: <20101107225916.0EE0A2A6C124@llvm.org>

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

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> 2010-11-07 16:59:15 CST ---
I added support for -rdynamic in 118384. I am marking this bug as fixed, please
reopen it the actual bug was something else.

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

From bugzilla-daemon at llvm.org  Sun Nov  7 21:41:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  7 Nov 2010 21:41:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 8230] invalid cast to reference to function is
	allowed
In-Reply-To: <bug-8230-206@http.llvm.org/bugs/>
References: <bug-8230-206@http.llvm.org/bugs/>
Message-ID: <20101108034137.16A382A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-07 21:41:36 CST ---
Fixed in Clang r118400, with Fasail's patch + minor tweaks.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 09:21:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 09:21:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 7425] function arguments which are const references
 fail to compile when passed an instantiation of a template function
In-Reply-To: <bug-7425-206@http.llvm.org/bugs/>
References: <bug-7425-206@http.llvm.org/bugs/>
Message-ID: <20101108152134.5E8202A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #8 from Douglas Gregor <dgregor at apple.com> 2010-11-08 09:21:33 CST ---
Fixed in Clang r118407.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 11:06:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 11:06:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 8553] False positive "garbage data"
In-Reply-To: <bug-8553-206@http.llvm.org/bugs/>
References: <bug-8553-206@http.llvm.org/bugs/>
Message-ID: <20101108170659.A058E2A6C12C@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #5 from Ted Kremenek <kremenek at apple.com> 2010-11-08 11:06:59 CST ---
(In reply to comment #4)
> (In reply to comment #3)
> > This issue doesn't reproduce on TOT clang.  What version of clang are you
> > using?
> 
> I am using the 2.7 package in Ubuntu Lucid Lynx 10.04.

Okay, this has been fixed since 2.7 was tagged.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 11:25:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 11:25:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 8322] Clang 2.8 Compile fails with: "address of
 overloaded function 'XXX' cannot be converted to type 'YYY' ",
 succeeds in GCC 4.4.1
In-Reply-To: <bug-8322-206@http.llvm.org/bugs/>
References: <bug-8322-206@http.llvm.org/bugs/>
Message-ID: <20101108172554.BA9C92A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2010-11-08 11:25:54 CST ---
Yes, this was a duplicate of PR7425. It's fixed now.

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

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

From bugzilla-daemon at llvm.org  Mon Nov  8 12:00:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 12:00:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 8565] New: llvm-mc cannot parse gcc output
Message-ID: <bug-8565-206@http.llvm.org/bugs/>

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

           Summary: llvm-mc cannot parse gcc output
           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


gcc 4.4.3 will compile

-------------------------------------
class ios_base   {
public: virtual ~ios_base();
};
class StrStream : virtual  public ios_base {
};
static void PrintTestPartResultToString() {
  new StrStream;
}
----------------------------------

into

.....
jmp    .LTHUNK0
.....
.set    .LTHUNK0,_ZN9StrStreamD1Ev

We currently reject that since we impose the semantics that a variable is
replaced base on what has been seen so far. It might be better to switch to a
full file semantics.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 12:07:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 12:07:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8566] New: Valgrind output does not include file
 and line number
Message-ID: <bug-8566-206@http.llvm.org/bugs/>

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

           Summary: Valgrind output does not include file and line number
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jed at 59a2.org
                CC: llvmbugs at cs.uiuc.edu


Linux, valgrind-3.6.0, clang-2.9 (trunk from this week), source compiled with
clang -g.  When source is compiled with gcc, valgrind traces include source
file and line number.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 12:35:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 12:35:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 8567] New: Incorrect code for VLA pointers
Message-ID: <bug-8567-206@http.llvm.org/bugs/>

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

           Summary: Incorrect code for VLA pointers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jed at 59a2.org
                CC: llvmbugs at cs.uiuc.edu


Problem is for pointer of form

double (*p)[n][5];

where n is a runtime parameter.  Test case attached.

$ gcc -Wall -std=c99 vla-bug.c && ./a.out
 test_static: size 15  diff 15
    test_var: size 15  diff 15
$ clang -Wall -std=c99 vla-bug.c && ./a.out
 test_static: size 15  diff 15
    test_var: size 15  diff 75

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

From bugzilla-daemon at llvm.org  Mon Nov  8 13:17:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 13:17:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 7905] clang c++ crash with compound literal with
 array with templated element type
In-Reply-To: <bug-7905-206@http.llvm.org/bugs/>
References: <bug-7905-206@http.llvm.org/bugs/>
Message-ID: <20101108191712.5AF592A6C12E@llvm.org>

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

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> 2010-11-08 13:17:11 CST ---
Fixed at r118428.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 13:24:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 13:24:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 8182] wrong constructor choice (templates)
In-Reply-To: <bug-8182-206@http.llvm.org/bugs/>
References: <bug-8182-206@http.llvm.org/bugs/>
Message-ID: <20101108192459.7626D2A6C135@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2010-11-08 13:24:58 CST ---
Fixed in Clang r118418.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 13:42:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 13:42:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8076] clang segfault with variably-modified
 function parameters.
In-Reply-To: <bug-8076-206@http.llvm.org/bugs/>
References: <bug-8076-206@http.llvm.org/bugs/>
Message-ID: <20101108194235.53CAD2A6C130@llvm.org>

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

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> 2010-11-08 13:42:34 CST ---
Works fine with trunk (r118428).

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

From bugzilla-daemon at llvm.org  Mon Nov  8 15:27:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 15:27:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 8211] Cannot yet select: 0x1e75fc0: v4f32 =
 X86ISD::MOVLPS 0x1e760c0, 0x1e775e0
In-Reply-To: <bug-8211-206@http.llvm.org/bugs/>
References: <bug-8211-206@http.llvm.org/bugs/>
Message-ID: <20101108212705.7EB382A6C124@llvm.org>

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

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> changed:

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

--- Comment #2 from Bruno Cardoso Lopes <bruno.cardoso at gmail.com> 2010-11-08 15:27:05 CST ---
At least the attached bitcode is still failing. I forgot about this one!
Commited in r118445.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 16:02:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 16:02:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 8558] TemplateArgumentLoc does not have expression
 field properly set.
In-Reply-To: <bug-8558-206@http.llvm.org/bugs/>
References: <bug-8558-206@http.llvm.org/bugs/>
Message-ID: <20101108220239.315842A6C12E@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dgregor at apple.com,
                   |                            |llvmbugs at cs.uiuc.edu,
                   |                            |nlewycky at google.com
          Component|Frontend                    |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 Nov  8 17:30:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 17:30:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 8001] not seeing declaration of constructors for
 previously declared template class
In-Reply-To: <bug-8001-206@http.llvm.org/bugs/>
References: <bug-8001-206@http.llvm.org/bugs/>
Message-ID: <20101108233031.1F2762A6C130@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #2 from Nick Lewycky <nlewycky at google.com> 2010-11-08 17:30:30 CST ---
Applied fix in r118454.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 18:27:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 18:27:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 8441] Race condition in AttributesList
In-Reply-To: <bug-8441-206@http.llvm.org/bugs/>
References: <bug-8441-206@http.llvm.org/bugs/>
Message-ID: <20101109002724.CEFE12A6C12D@llvm.org>

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

Owen Anderson <resistor at mac.com> changed:

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

--- Comment #2 from Owen Anderson <resistor at mac.com> 2010-11-08 18:27:24 CST ---
Fixed in r118461.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 18:36:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 18:36:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 8442] Thread unsafety in DynamicLibrary.cpp
In-Reply-To: <bug-8442-206@http.llvm.org/bugs/>
References: <bug-8442-206@http.llvm.org/bugs/>
Message-ID: <20101109003620.A2EA52A6C12D@llvm.org>

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

Owen Anderson <resistor at mac.com> changed:

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

--- Comment #2 from Owen Anderson <resistor at mac.com> 2010-11-08 18:36:20 CST ---
Fixed in r118463.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 18:38:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 18:38:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8568] New: Objective-C: warn if a retain property
 setter doesn't retain (or an assign does)
Message-ID: <bug-8568-206@http.llvm.org/bugs/>

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

           Summary: Objective-C: warn if a retain property setter doesn't
                    retain (or an assign does)
           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: kyle at omnigroup.com
                CC: llvmbugs at cs.uiuc.edu


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

It's common to accidentally provide a property setter implementation that
doesn't follow the memory management contract specified in the property
declaration. The analyzer should catch cases in which the argument to a retain
property setter goes out of scope without an incremented retain count, as well
as cases in which the argument to an assign property setter goes out of scope
with an incremented retain count.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 19:09:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 19:09:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 8569] New: Missing assertion propagation
Message-ID: <bug-8569-206@http.llvm.org/bugs/>

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

           Summary: Missing assertion propagation
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xinliangli at gmail.com
                CC: llvmbugs at cs.uiuc.edu, xinliangli at gmail.com


Trivial Test:

int g;
int foo (int i)
{

   if (i == 1)
   {
      g = i + 1;
   }
   else if (i == 10)
      g = 2*i;

  return g;
}

Clang -O2 -fomit-frame-pointer generates:


foo:
.Leh_func_begin0:
    cmpl    $1, %edi
    je    .LBB0_3
    cmpl    $10, %edi
    je    .LBB0_4
    movl    g(%rip), %eax
    ret
.LBB0_3:
    incl    %edi               <---
    movl    %edi, g(%rip)      <---
    movl    $2, %eax
    ret
.LBB0_4:
    addl    %edi, %edi        <---
    movl    %edi, g(%rip)     <---
    movl    $20, %eax
    ret


Compared with gcc -O2 result:


.LFB0:
    .cfi_startproc
    cmpl    $1, %edi
    je    .L6
    cmpl    $10, %edi
    je    .L4
    movl    g(%rip), %eax
    ret
    .p2align 4,,10
    .p2align 3
.L4:
    movl    $20, g(%rip)
    movl    $20, %eax
    ret
    .p2align 4,,10
    .p2align 3
.L6:
    movl    $2, g(%rip)
    movl    $2, %eax
    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  Mon Nov  8 19:19:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 19:19:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 7611] Not emitting covariant thunk
In-Reply-To: <bug-7611-206@http.llvm.org/bugs/>
References: <bug-7611-206@http.llvm.org/bugs/>
Message-ID: <20101109011921.695912A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-11-08 19:19:20 CST ---
Fixed in r118466.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 19:32:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 19:32:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8567] Incorrect code for VLA pointers
In-Reply-To: <bug-8567-206@http.llvm.org/bugs/>
References: <bug-8567-206@http.llvm.org/bugs/>
Message-ID: <20101109013246.2101E2A6C124@llvm.org>

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

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> 2010-11-08 19:32:45 CST ---
Fixed at r118468.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 19:51:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 19:51:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 6060] Crash in 2D VLA arrays in function arguments
In-Reply-To: <bug-6060-206@http.llvm.org/bugs/>
References: <bug-6060-206@http.llvm.org/bugs/>
Message-ID: <20101109015121.B9A3E2A6C12D@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #1 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2010-11-08 19:51:19 CST ---
Works fine on trunk (r118468).

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

From bugzilla-daemon at llvm.org  Mon Nov  8 21:31:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 21:31:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 8025] clang c++ diagnostic for bitfield with
 non-integral type missing source location
In-Reply-To: <bug-8025-206@http.llvm.org/bugs/>
References: <bug-8025-206@http.llvm.org/bugs/>
Message-ID: <20101109033143.A78DD2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-08 21:31:43 CST ---
Fixed in Clang r118481 by Jakub's patch.

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

From bugzilla-daemon at llvm.org  Mon Nov  8 23:19:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  8 Nov 2010 23:19:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 8570] New: Segfault while passing variable-sized
	arrays.
Message-ID: <bug-8570-206@http.llvm.org/bugs/>

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

           Summary: Segfault while passing variable-sized arrays.
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: cg.wowus.cg at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5752)
 --> (http://llvm.org/bugs/attachment.cgi?id=5752)
The crashing program.

I have attached a short, 16 line program which segfaults the clang front end. I
believe I've reduced it down as far as possible, and don't really know what to
do with it next. My workaround at the moment is to just use llvm-gcc -std=c99.

Compiling:

    clang bug.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 Nov  9 01:17:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 01:17:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 8571] New: Missing store sinking
Message-ID: <bug-8571-206@http.llvm.org/bugs/>

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

           Summary: Missing store sinking
           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: xinliangli at gmail.com
                CC: llvmbugs at cs.uiuc.edu


// Test case

struct A { 
 int a;
 int b;
};


int foo (struct A *this, int n, int m ) 
{
   int s = 0;


   if (__builtin_expect(m,0))
   {   
     s = this->a;
   }   
   else
   {   
     this->a = m;        // should be sinked
   }   

   if (__builtin_expect (n,1))
   {   
     this->a = n;
   }   

   return s;
}

// -O2 output:



foo:
.Leh_func_begin0:
        pushq   %rbp
.Ltmp0: 
        movq    %rsp, %rbp
.Ltmp1:
        testl   %edx, %edx
        je      .LBB0_2
        movl    (%rdi), %eax
        jmp     .LBB0_3
.LBB0_2: 
        movl    %edx, (%rdi)         #  Partially dead store not sinked
        xorl    %eax, %eax
.LBB0_3:
        testl   %esi, %esi
        je      .LBB0_5
        movl    %esi, (%rdi)
.LBB0_5:
        popq    %rbp
        ret




David

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

From bugzilla-daemon at llvm.org  Tue Nov  9 02:10:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 02:10:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 8572] New: Incomplete type based aliasing support
Message-ID: <bug-8572-206@http.llvm.org/bugs/>

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

           Summary: Incomplete type based aliasing support
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xinliangli at gmail.com
                CC: llvmbugs at cs.uiuc.edu, xinliangli at gmail.com


This is probably a known limitation as the tbaa support is unfinished.

Test case:


truct BUF1
{
  int b1; 
  int b12;
};

struct BUF2
{
  int b2; 
  int g;
};


int foo(int n, struct BUF1* p, struct BUF2* q)
{
    int i = 0;
    for (i = 0; i < n; i++)
    {   
        p->b1 += q->b2;
    }   
    return 0;
}


// gcc -O2 generates:


 6 foo:
  7 .LFB0:
  8         .cfi_startproc
  9         testl   %edi, %edi
 10         jle     .L2
 11         movl    (%rdx), %eax
 12         decl    %edi
 13         movl    (%rsi), %edx
 14         imull   %eax, %edi
 15         addl    %eax, %edx
 16         addl    %edx, %edi
 17         movl    %edi, (%rsi)
 18 .L2:
 19         xorl    %eax, %eax
 20         ret


// clang -O2 -fomit-frame-pointer -mllvm -enable-tbaa generates:


 6 foo:
  7 .Leh_func_begin0:
  8         testl   %edi, %edi
  9         jle     .LBB0_3
 10         movl    (%rsi), %eax
 11         .align  16, 0x90
 12 .LBB0_2:
 13         addl    (%rdx), %eax
 14         movl    %eax, (%rsi)
 15         decl    %edi
 16         jne     .LBB0_2
 17 .LBB0_3:
 18         xorl    %eax, %eax
 19         ret


Gcc flattens the loop and folds the computation, but llvm keeps the loop with
load and store.

Note for simple scalar type, llvm works fine.

Example from SPEC06 libquantum:

1 typedef struct quantum_reg_node_struct {
  2    int state;
  3 } quantum_reg_node;
  4 
  5 typedef struct quantum_reg_struct {
  6    int size; quantum_reg_node* node;
  7 } quantum_reg;
  8 
  9 void foo( quantum_reg* reg,int target)
 10 {
 11    int i;
 12    for (i = 0 ; i < reg->size; i++)
 13    {
 14       reg->node[i].state^= (1<< target);
 15    }
 16 }

The load of reg->size and reg->node should be hoisted out of the loop.

Loop from gcc:

19 .L3:
 20         xorl    %edx, (%rax,%rcx,4)
 21         incq    %rcx
 22         cmpl    %ecx, %r8d
 23         jg      .L3

Loop from clang/llvm:

16 .LBB0_2:
 17         xorl    %eax, (%rcx,%rdx,4)
 18         incq    %rdx
 19         cmpl    (%rdi), %edx          <--- extra load
 20         jl      .LBB0_2


David

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

From bugzilla-daemon at llvm.org  Tue Nov  9 08:22:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 08:22:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8573] New: Cannot yet select: intrinsic
	%llvm.x86.sse3.monitor
Message-ID: <bug-8573-206@http.llvm.org/bugs/>

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

           Summary: Cannot yet select: intrinsic %llvm.x86.sse3.monitor
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


This is on x86-64 linux.  The testcase is pr27696.c from the gcc testsuite.

$ llvm-gcc -S -msse3 pr27696.c
cc1: error in backend: Cannot yet select: intrinsic %llvm.x86.sse3.monitor
$ cat pr27696.c
/* PR target/27696
   The testcase below uses to trigger an ICE.  */

/* { dg-do compile } */
/* { dg-options "-msse3" } */

void
foo (void const * P, unsigned int E, unsigned int H)
{
  __builtin_ia32_monitor (P, E, H);
}

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

From bugzilla-daemon at llvm.org  Tue Nov  9 10:13:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 10:13:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 8013] clang c++ calling address of overload set
	fails
In-Reply-To: <bug-8013-206@http.llvm.org/bugs/>
References: <bug-8013-206@http.llvm.org/bugs/>
Message-ID: <20101109161354.D52E12A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-09 10:13:54 CST ---
Fixed in Clang r118508.

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

From bugzilla-daemon at llvm.org  Tue Nov  9 11:48:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 11:48:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 8570] Segfault while passing variable-sized arrays.
In-Reply-To: <bug-8570-206@http.llvm.org/bugs/>
References: <bug-8570-206@http.llvm.org/bugs/>
Message-ID: <20101109174824.DF33F2A6C12D@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #2 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2010-11-09 11:48:24 CST ---
Works fine on trunk (r118514).

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

From bugzilla-daemon at llvm.org  Tue Nov  9 12:11:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 12:11:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 6842] inliner inlines recursive call,
	defeats loop-deletion
In-Reply-To: <bug-6842-206@http.llvm.org/bugs/>
References: <bug-6842-206@http.llvm.org/bugs/>
Message-ID: <20101109181153.78A4D2A6C12C@llvm.org>

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

Owen Anderson <resistor at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |resistor at mac.com
         Resolution|                            |WORKSFORME

--- Comment #4 from Owen Anderson <resistor at mac.com> 2010-11-09 12:11:52 CST ---
This seems to be fixed now.  opt -O2 reduces the testcase to "return 10000;"

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

From bugzilla-daemon at llvm.org  Tue Nov  9 14:04:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 14:04:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8013] clang c++ calling address of overload set
	fails
In-Reply-To: <bug-8013-206@http.llvm.org/bugs/>
References: <bug-8013-206@http.llvm.org/bugs/>
Message-ID: <20101109200435.994DE2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |INVALID

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-09 14:04:35 CST ---
Update: GCC and Clang were actually correct to reject this code. I've reverted
the fix in 118620; see that commit for a more detailed discussion.

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

From bugzilla-daemon at llvm.org  Tue Nov  9 14:14:55 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 14:14:55 -0600 (CST)
Subject: [LLVMbugs] [Bug 8380] Assertion `StartColNo <= EndColNo && "Invalid
 range!"' on invalid code
In-Reply-To: <bug-8380-206@http.llvm.org/bugs/>
References: <bug-8380-206@http.llvm.org/bugs/>
Message-ID: <20101109201455.78E7D2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-09 14:14:54 CST ---
Fixed in r118625, thanks!

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

From bugzilla-daemon at llvm.org  Tue Nov  9 15:09:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 15:09:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 7863] Function template and ?: causes segfault
In-Reply-To: <bug-7863-206@http.llvm.org/bugs/>
References: <bug-7863-206@http.llvm.org/bugs/>
Message-ID: <20101109210904.DD2B42A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #9 from Douglas Gregor <dgregor at apple.com> 2010-11-09 15:09:04 CST ---
Fixed in Clang r118631.

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

From bugzilla-daemon at llvm.org  Tue Nov  9 15:20:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 15:20:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 8574] New: Assert when doing -ast-dump
Message-ID: <bug-8574-206@http.llvm.org/bugs/>

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

           Summary: Assert when doing -ast-dump
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jim at thegoodnows.net
                CC: llvmbugs at cs.uiuc.edu


Invoking "clang -cc1 -ast-dump t.cpp" where t.cpp just contains:

#include <vector>

results in the following:

clang:
/home/jimg/llvm/tools/clang/lib/Basic/../../include/clang/Basic/SourceManager.h:274:
const clang::SrcMgr::FileInfo& clang::SrcMgr::SLocEntry::getFile() const:
Assertion `isFile() && "Not a file SLocEntry!"' failed.
0  libLLVM-2.9svn.so 0x01a62708
Stack dump:
0.    Program arguments: clang -cc1 -ast-dump t.cpp 
1.    <eof> parser at end of file

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

From bugzilla-daemon at llvm.org  Tue Nov  9 15:49:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 15:49:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 8575] New: missing code cleanup after jump threading
Message-ID: <bug-8575-206@http.llvm.org/bugs/>

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

           Summary: missing code cleanup after jump threading
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xinliangli at gmail.com
                CC: llvmbugs at cs.uiuc.edu, xinliangli at gmail.com


// Test case

int g;
void foo(int n, int m)
{

    int r = 0;
    if (n  > m)
    {
       r = 1;
    }
    else {
       r = 3;
    }

    if (r < 2)
    {
       g = r;

    }
    else
      g = r+ 3;

}

// Clang -O2 -fomit-frame-pointer produces:
.Leh_func_begin0:
    cmpl    %esi, %edi
    setle    %al
    movzbl    %al, %eax
    leal    1(%rax,%rax), %eax
    jle    .LBB0_2
    movl    %eax, g(%rip)
    ret
.LBB0_2:
    addl    $3, %eax
    movl    %eax, g(%rip)
    ret
.Ltmp0:


// Gcc -O2 produces:

.LFB0:
    .cfi_startproc
    xorl    %eax, %eax
    cmpl    %esi, %edi
    setle    %al
    leal    1(%rax,%rax,4), %eax
    movl    %eax, g(%rip)
    ret

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

From bugzilla-daemon at llvm.org  Tue Nov  9 16:17:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 16:17:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 8576] New: Missing dead store elimination
Message-ID: <bug-8576-206@http.llvm.org/bugs/>

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

           Summary: Missing dead store elimination
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xinliangli at gmail.com
                CC: llvmbugs at cs.uiuc.edu, xinliangli at gmail.com


void foo(int *p, int*q)
{

   *p = 10;   <-- this is not eliminated by clang/llvm but gcc does it
   *q = 20; 
   *p = 30;
}


(Does LLVM chain up the may-defs via def-def chain?)


David

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

From bugzilla-daemon at llvm.org  Tue Nov  9 16:53:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 16:53:02 -0600 (CST)
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: <20101109225302.6C0882A6C130@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-09 16:53:01 CST ---
I think Clang is behaving correctly (or, at least, reasonably) here.
Instantiating the definition of a static data member shouldn't change its type,
since we can choose any "use" at which to instantiate it. Admittedly, this is a
grey area of the standard, and implementations are split: GCC allows the code,
EDG and Clang rejects it.

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

From bugzilla-daemon at llvm.org  Tue Nov  9 17:02:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 17:02:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8577] New: improve side effect modelling of
 standard lib functions
Message-ID: <bug-8577-206@http.llvm.org/bugs/>

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

           Summary: improve side effect modelling of standard lib
                    functions
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xinliangli at gmail.com
                CC: llvmbugs at cs.uiuc.edu, xinliangli at gmail.com


#include <math.h>

int g = 1, g2;
 double d = 1;
void foo()
{

    g = 1;
    d = exp(d);
    g2 = g;
}


g = 1 should be const propagated. Clang does not do this even with -ffast-math.
Gcc is also weak, but it treats exp as pure when -ffast-math is specified.


David

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

From bugzilla-daemon at llvm.org  Tue Nov  9 17:11:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 17:11:47 -0600 (CST)
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: <20101109231147.AB6F22A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-09 17:11:47 CST ---
Re-opened by popular demand. Squinting at C++ [temp.inst]p1 in the right way
would make this 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  Tue Nov  9 19:31:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 19:31:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 8547] likely x86 miscompile using clang
In-Reply-To: <bug-8547-206@http.llvm.org/bugs/>
References: <bug-8547-206@http.llvm.org/bugs/>
Message-ID: <20101110013134.9A24E2A6C12E@llvm.org>

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

Dale Johannesen <dalej at apple.com> changed:

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

--- Comment #4 from Dale Johannesen <dalej at apple.com> 2010-11-09 19:31:34 CST ---
Fixed in 118665.

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

From bugzilla-daemon at llvm.org  Tue Nov  9 19:45:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 19:45:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 8554] clang fails GCC test 20020614.c: illegal
 simplifications when folding constants
In-Reply-To: <bug-8554-206@http.llvm.org/bugs/>
References: <bug-8554-206@http.llvm.org/bugs/>
Message-ID: <20101110014522.E73092A6C12E@llvm.org>

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

Dale Johannesen <dalej at apple.com> changed:

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

--- Comment #4 from Dale Johannesen <dalej at apple.com> 2010-11-09 19:45:22 CST ---
This seems fixed now.  I think 118471 did it, not entirely sure.

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

From bugzilla-daemon at llvm.org  Tue Nov  9 20:41:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 20:41:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 8022] clang c++ assertion "Invalid Scope." on
 invalid template using directive
In-Reply-To: <bug-8022-206@http.llvm.org/bugs/>
References: <bug-8022-206@http.llvm.org/bugs/>
Message-ID: <20101110024109.9333A2A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-11-09 20:41:09 CST ---
Fixed in r118669.

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

From bugzilla-daemon at llvm.org  Tue Nov  9 21:02:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  9 Nov 2010 21:02:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 7915] clang c++ crash declaring friend with same
 name as containing class
In-Reply-To: <bug-7915-206@http.llvm.org/bugs/>
References: <bug-7915-206@http.llvm.org/bugs/>
Message-ID: <20101110030253.A2D2A2A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-11-09 21:02:53 CST ---
Fixed in r118670.

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

From bugzilla-daemon at llvm.org  Wed Nov 10 00:49:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 00:49:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 8578] New: clang segfault
Message-ID: <bug-8578-206@http.llvm.org/bugs/>

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

           Summary: clang segfault
           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 n10 tmp900]$ clang -v

clang version 2.9 (trunk 118666)
Target: i386-pc-linux-gnu
Thread model: posix

[regehr at n10 tmp900]$ clang -O3 -c small.c -w

clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at n10 tmp900]$ cat small.c

struct S1
{
  signed f1:1;
};

unsigned char g_85;

struct S1 g_101 = {
  1068
};

struct S1 func_70 (struct S1 p_71)
{
  if (0)
    {
    }
  else
    {
      unsigned char t_260;
      unsigned char l_259;
      for (l_259 = 0;; l_259 = (t_260 = l_259, t_260 ^ 0 & -1 ^ 0 ? : -1))
    {
      unsigned char t_263;
      signed char t_264;
      signed char t_265;
      unsigned char *l_266 = &g_85;
      *l_266 ^= (p_71.f1, t_263 =
             (t_264 = g_101.f1, t_265 = l_259, t_264 > 0 && t_265 > 0
              && 0 > -t_265 || t_264 < 0 && t_265 < 0
              && 1 - 0 ? : +1), 0 ? : +t_263);
    }
    }
}

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

From bugzilla-daemon at llvm.org  Wed Nov 10 02:40:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 02:40:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 8527] Win32/Process.inc: "NUL" is not display
 device(opt -o nul fails)
In-Reply-To: <bug-8527-206@http.llvm.org/bugs/>
References: <bug-8527-206@http.llvm.org/bugs/>
Message-ID: <20101110084057.447EC2A6C12D@llvm.org>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #2 from NAKAMURA Takumi <geek4civic at gmail.com> 2010-11-10 02:40:56 CST ---
Fixed in r118678, thank you!

(In reply to comment #1)
> Takumi, I think you're the expert here, go ahead and consider windows-specific
> patches like this preapproved.  If you think that something is controversial,
> llvm-commits is the right place to discuss them (with Michael etc).

I will post and ask one on the list whenever I feel it might be sensitive.

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

From bugzilla-daemon at llvm.org  Wed Nov 10 03:41:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 03:41:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 8579] New: clang test failure: Driver/hello.c
Message-ID: <bug-8579-206@http.llvm.org/bugs/>

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

           Summary: clang test failure: Driver/hello.c
           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


pipping at bogus ~/tmp/llvm/tools/clang/test $ ./TestRunner.sh -v Driver/hello.c
lit.py: lit.cfg:130: note: using clang:
'/home/pipping/tmp/llvm/Release+Asserts/bin/clang'
-- Testing: 1 tests, 2 threads --
FAIL: Clang :: Driver/hello.c (1 of 1)
******************** TEST 'Clang :: Driver/hello.c' FAILED ********************
Script:
--
/home/pipping/tmp/llvm/Release+Asserts/bin/clang  -ccc-echo -o
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp
/home/pipping/tmp/llvm/tools/clang/test/Driver/hello.c 2>
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp.log
grep 'clang" -cc1 .*hello.c'
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp.log
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp >
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp.out
grep "I'm a little driver, short and stout."
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp.out
--
Exit Code: 1

********************
Testing Time: 0.11s
********************
Failing Tests (1):
    Clang :: Driver/hello.c

  Unexpected Failures: 1
pipping at bogus ~/tmp/llvm/tools/clang/test $ 

pipping at bogus ~/tmp/llvm/tools/clang/test $ cat Driver/Output/hello.c.script 
/home/pipping/tmp/llvm/Release+Asserts/bin/clang  -ccc-echo -o
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp
/home/pipping/tmp/llvm/tools/clang/test/Driver/hello.c 2>
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp.log &&
grep 'clang" -cc1 .*hello.c'
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp.log &&
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp >
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp.out &&
grep "I'm a little driver, short and stout."
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp.out
pipping at bogus ~/tmp/llvm/tools/clang/test $ cat Driver/Output/hello.c.tmp.log 
 "/home/pipping/tmp/llvm/Release+Asserts/bin/clang" -cc1 -triple
x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name hello.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1.20100303
-resource-dir /home/pipping/tmp/llvm/Release+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 0 -fgnu-runtime -fdiagnostics-show-option -o
/tmp/cc-ZLFolF.o -x c /home/pipping/tmp/llvm/tools/clang/test/Driver/hello.c
 "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o
/home/pipping/tmp/llvm/tools/clang/test/Driver/Output/hello.c.tmp
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o crtbegin.o -L
-L/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/../../..
/tmp/cc-ZLFolF.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed crtend.o /usr/lib/../lib64/crtn.o
/usr/bin/ld: error: cannot open crtbegin.o: No such file or directory
/usr/bin/ld: error: cannot open crtend.o: No such file or directory
/usr/bin/ld: error: cannot find -lgcc
/usr/bin/ld: error: cannot find -lgcc
clang: error: linker command failed with exit code 1 (use -v to see invocation)
pipping at bogus ~/tmp/llvm/tools/clang/test $ 

I tracked this down to the following commit:

Author: Rafael Espindola <rafael.espindola at gmail.com>
Date:   Sun Nov 7 20:14:31 2010 +0000

    Use ld directly on linux. Changes from the previous try:
    *) Try to detect as much as possible from the system itself, not the
distro.
       This should make it easier to port to a new distro and more likely to
       work on a unknown one.
    *) The distro enum now doesn't include the arch. Just use the existing
       host detection support in LLVM.
    *) Correctly handle --sysroot.

    A small regression is that now clang will pass bitcode file to the linker.
    This is necessary for the gold plugin support to work.

    It might be better to detect this at configure/cmake time, but doing it in
    c++ first is a lot easier.

    git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk at 118382

That test passes with any revision prior to 118382 but none after.

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

From bugzilla-daemon at llvm.org  Wed Nov 10 04:21:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 04:21:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 8580] New: clang error recovery goes wrong after
 qualifier mismatch
Message-ID: <bug-8580-206@http.llvm.org/bugs/>

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

           Summary: clang error recovery goes wrong after qualifier
                    mismatch
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Cut down testcase:


struct Foo
{
  virtual const Foo *Get() const { return this; }
};
struct Bar : Foo
{
} f;

const Foo *GetFoo() { return &f; }

int main()
{
  Foo *foo = GetFoo();
  dynamic_cast<const Bar*>(foo->Get());
}


g++ does well here:

test.cpp: In function ?int main()?:
test.cpp:13: error: invalid conversion from ?const Foo*? to ?Foo*?


clang++ does badly:

test.cpp:13:8: error: cannot initialize a variable of type 'Foo *' with an
rvalue of type 'Foo const *'
  Foo *foo = GetFoo();
       ^     ~~~~~~~~
test.cpp:14:31: error: expected ')'
  dynamic_cast<const Bar*>(foo->Get());
                              ^
test.cpp:14:27: note: to match this '('
  dynamic_cast<const Bar*>(foo->Get());
                          ^
2 errors generated.


The first error is OK (though a fixit adding in the const would be nice). The
second error is weird and unhelpful. I get the same error if I instead declare
foo as type void: even if this were a correct error, it would seem more helpful
to produce the "member reference type 'void' is not a pointer" error.

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

From bugzilla-daemon at llvm.org  Wed Nov 10 04:23:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 04:23:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 8581] New: Duplicate diagnostic initializing a
 local variable of type 'void'
Message-ID: <bug-8581-206@http.llvm.org/bugs/>

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

           Summary: Duplicate diagnostic initializing a local variable of
                    type 'void'
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


This testcase:

void *a;
int main()
{
  void b = a;
}


Produces the same error twice:

test.cpp:4:8: error: variable has incomplete type 'void'
  void b = a;
       ^
test.cpp:4:8: error: variable has incomplete type 'void'                        
2 errors generated.


A single error would be preferable. A fixit adding the * would be even better!

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

From bugzilla-daemon at llvm.org  Wed Nov 10 13:25:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 13:25:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 8582] New: Assertion `N.getNode()->getNodeId() !=
 NewNode && "Mapped to new node!"' failed.
Message-ID: <bug-8582-206@http.llvm.org/bugs/>

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

           Summary: Assertion `N.getNode()->getNodeId() != NewNode &&
                    "Mapped to new node!"' 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 n7 tmp700]$ clang -v

clang version 2.9 (trunk 118666)
Target: i386-pc-linux-gnu
Thread model: posix

[regehr at n7 tmp700]$ clang -O2 -c small.c -w

clang: LegalizeTypes.cpp:622: void
llvm::DAGTypeLegalizer::RemapValue(llvm::SDValue&): Assertion
`N.getNode()->getNodeId() != NewNode && "Mapped to new node!"' failed.
0  clang 0x093ebbd8
Stack dump:
0.    Program arguments:
/mnt/local/randomtest/compiler-install/llvm-gcc-r118666-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.1 -resource-dir
/mnt/local/randomtest/compiler-install/llvm-gcc-r118666-install/bin/../lib/clang/2.9
-O2 -w -ferror-limit 19 -fmessage-length 108 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'small.c'.
4.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@uint82'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at n7 tmp700]$ cat small.c

struct S0
{
  const int int32f0;
  const int uint16f1;
  unsigned char f3;
  int f4;
};

struct S1
{
  struct S0 f0;
  signed f1:3;
  unsigned f2:22;
  signed f3:1;
  unsigned f4:7;
  const signed f5:14;
  signed f6:12;
};

struct S2
{
  unsigned char f0;
  const int uint32f1;
  struct S0 f2;
  struct S0 f3;
  const struct S1 f4;
  unsigned char f5;
  struct S0 f6;
  unsigned char f7;
};

struct S3
{
  struct S2 f0;
  signed f1:29;
  unsigned char f2;
  const struct S0 f3;
  int f4;
};

unsigned char g_419;
unsigned char *g_426 = &g_419;

struct S1 g_564 = {
  1, 1, 0, 0x426E79C4
};

void uint82 (int * p_13, unsigned char p_14)
{
  unsigned char t_817;
  if (t_817 = *g_426, t_817)
    {
      int t_843;
      unsigned char t_844;
      struct S1 l_827 = {
    -5, 1, 0,
      };
      struct S3 l_833 = {
    1, 0, 7, 1, 0xEF6AB0B8
      };
      for (g_564.f0.f4; g_564.f0.f4; g_564.f0.f4 = g_564.f0.f4, +0)
    {
      *p_13 |= func_96 (l_827, l_833, 0);
    }
      for (l_833.f4;
       l_833.f4 > 0;
       l_833.f4 = (t_843 = l_833.f4, 1 > 0 && 1 > 0
               && t_843 > 2147483647 - 1 || t_843 < 0
               && t_844 < 0 ? t_843 : t_843 + 1))
    *g_426 = 0;
    }
}

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

From bugzilla-daemon at llvm.org  Wed Nov 10 14:49:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 14:49:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 8578] clang segfault
In-Reply-To: <bug-8578-206@http.llvm.org/bugs/>
References: <bug-8578-206@http.llvm.org/bugs/>
Message-ID: <20101110204900.BAD7C2A6C12C@llvm.org>

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

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

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

--- Comment #4 from John Regehr <regehr at cs.utah.edu> 2010-11-10 14:49:00 CST ---
Works 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  Wed Nov 10 15:56:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 15:56:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 8583] New: internalconstant is invalid bitcode
 signature in helloworld example
Message-ID: <bug-8583-206@http.llvm.org/bugs/>

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

           Summary: internalconstant is invalid bitcode signature in
                    helloworld example
           Product: Website
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alfred at 54.org
                CC: llvmbugs at cs.uiuc.edu


http://llvm.org/docs/LangRef.html#highlevel
The hello world example has an error:
@.LC0 = internalconstant[13 x i8] c"hello world\0A\00"      ; [13 x i8]* 
        ^
lli: error loading program '-': Invalid bitcode signature

"internalconstant" should have a space "internal constant"


BTW, I had to delete the metadata stuff at the bottom to get it to compile:

llvm-as: b.ll:19:14: error: Expected '!' here
!foo = !{!1, null}
             ^
lli: error loading program '-': Invalid bitcode signature

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

From bugzilla-daemon at llvm.org  Wed Nov 10 17:39:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 17:39:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 8585] New: clang wrong at -O0?
Message-ID: <bug-8585-206@http.llvm.org/bugs/>

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

           Summary: clang wrong at -O0?
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            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


A strange case.  We think the code is OK.  Uncharacteristically, it looks like
the -O0 result is wrong.

[regehr at n10 ~]$ clang -v
clang version 2.9 (trunk 118711)
Target: i386-pc-linux-gnu
Thread model: posix
[regehr at n10 ~]$ clang -O0 foo.c -o foo
[regehr at n10 ~]$ ./foo
g_5.f0 = 0
[regehr at n10 ~]$ clang -O1 foo.c -o foo
[regehr at n10 ~]$ ./foo
g_5.f0 = 1
[regehr at n10 ~]$ cat foo.c
struct S3 {
  int f0;
  unsigned f2 : 16;
};

struct S3 g_5 = {0,40000};

int printf(const char *format, ...);

void  func_1(void)
{
   int *l_9 = &g_5.f0;
   int g_2 = 0;
     for (g_2 = 0; g_2 < -1; g_2++)
   {
   }
   *l_9 = g_5.f2 >= 0;
   printf("g_5.f0 = %d\n", g_5.f0);
}

int main(int argc, char* argv[])
{
   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  Wed Nov 10 19:40:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 19:40:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 8586] New: Missing PRE
Message-ID: <bug-8586-206@http.llvm.org/bugs/>

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

           Summary: Missing PRE
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xinliangli at gmail.com
                CC: llvmbugs at cs.uiuc.edu, xinliangli at gmail.com


int a[100];
int foo(int x, int* y, int z)
{ 
  int m; 
  if (x)
  {
//     *y = z;
     a[x]  = z;
  }
  m = *y; 
  return m + a[x];      // <-- a[x] here is not PREed by LLVM.

}


David

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

From bugzilla-daemon at llvm.org  Wed Nov 10 20:09:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 10 Nov 2010 20:09:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 8579] [clang] Support Exherbo Linux in
 lib/Driver/ToolChains.cpp
In-Reply-To: <bug-8579-206@http.llvm.org/bugs/>
References: <bug-8579-206@http.llvm.org/bugs/>
Message-ID: <20101111020954.663602A6C124@llvm.org>

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

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> 2010-11-10 20:09:53 CST ---
I committed your patch as 118769. Thanks!

If you want to be sure clang is behaving just like gcc (the driver), you can
try the attached script. It runs gcc and g++ in various configurations and
compares the ld command 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  Thu Nov 11 13:37:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 13:37:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 8588] New: Clang crashes when using
	__attribute__((alias("")))
Message-ID: <bug-8588-206@http.llvm.org/bugs/>

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

           Summary: Clang crashes when using __attribute__((alias("")))
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: js-llvm-bugzilla at webkeks.org
                CC: llvmbugs at cs.uiuc.edu


avalon:/tmp$ cat test.m
extern void *foo __attribute__((alias("OBJC_CLASS_$_Foo")));

@interface Foo
@end

@implementation Foo
@end

avalon:/tmp$ clang -c test.m
Assertion failed: (C->getType() == T->getElementType(I-V.begin()) &&
"Initializer for struct element doesn't match struct element type!"), function
ConstantStruct, file Constants.cpp, line 555.
0  clang             0x0000000101404ae2 std::vector<llvm::sys::Path,
std::allocator<llvm::sys::Path>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::sys::Path*,
std::vector<llvm::sys::Path, std::allocator<llvm::sys::Path> > >,
llvm::sys::Path const&) + 11746
1  clang             0x0000000101405933 std::vector<llvm::sys::Path,
std::allocator<llvm::sys::Path>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::sys::Path*,
std::vector<llvm::sys::Path, std::allocator<llvm::sys::Path> > >,
llvm::sys::Path const&) + 15411
2  libSystem.B.dylib 0x00007fff8782c67a _sigtramp + 26
3  libSystem.B.dylib 0x0000000000000038 _sigtramp + 2021472728
4  clang             0x0000000100017862
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&) + 4274
5  clang             0x00000001012840c0 llvm::cast_retty<llvm::StructType,
llvm::CompositeType const*>::ret_type llvm::cast<llvm::StructType,
llvm::CompositeType const*>(llvm::CompositeType const* const&) + 14720
6  clang             0x000000010129d89e
llvm::ConstantUniqueMap<std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> >, llvm::StructType, llvm::ConstantStruct,
true>::Create(llvm::StructType const*, std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> > const&,
std::_Rb_tree_iterator<std::pair<std::pair<llvm::StructType const*,
std::vector<llvm::Constant*, std::allocator<llvm::Constant*> > > const,
llvm::ConstantStruct*> >) + 78
7  clang             0x00000001012896ce llvm::cast_retty<llvm::StructType,
llvm::CompositeType const*>::ret_type llvm::cast<llvm::StructType,
llvm::CompositeType const*>(llvm::CompositeType const* const&) + 36750
8  clang             0x0000000100242b34 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 70484
9  clang             0x0000000100257878 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 155800
10 clang             0x00000001002a4076 llvm::DenseMap<clang::Expr const*,
llvm::Value*, llvm::DenseMapInfo<clang::Expr const*>,
llvm::DenseMapInfo<llvm::Value*> >::grow(unsigned int) + 46182
11 clang             0x00000001002c62cc
llvm::SmallVectorTemplateBase<llvm::APInt, false>::grow(unsigned long) + 1468
12 clang             0x000000010028d98b
clang::ASTRecordLayout::getVBaseClassOffsetInBits(clang::CXXRecordDecl const*)
const + 2043
13 clang             0x00000001002d24e6 llvm::GetElementPtrInst*
llvm::GetElementPtrInst::CreateInBounds<llvm::Value**>(llvm::Value*,
llvm::Value**, llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 710
14 clang             0x000000010028e20c
clang::ASTRecordLayout::getVBaseClassOffsetInBits(clang::CXXRecordDecl const*)
const + 4220
15 clang             0x000000010004e319 llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 7849
16 clang             0x000000010002114e llvm::raw_ostream::operator<<(char
const*) + 1742
17 clang             0x0000000100019175
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&) + 10693
18 clang             0x00000001000200d4 std::vector<std::string,
std::allocator<std::string> >::operator=(std::vector<std::string,
std::allocator<std::string> > const&) + 11604
19 clang             0x0000000100017b38
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&) + 5000
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -emit-obj -mrelax-all -disable-free -main-file-name
test.m -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu
core2 -target-linker-version 97.14 -resource-dir
/usr/local/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 80
-stack-protector 1 -fblocks -fexceptions -fobjc-nonfragile-abi2
-fobjc-dispatch-method=mixed -fdiagnostics-show-option -fcolor-diagnostics -o
test.o -x objective-c test.m 
1.    <eof> parser at end of file
2.    test.m:6:1: LLVM IR generation of declaration 'Foo'
clang: error: unable to execute command: Illegal instruction
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 Nov 11 14:22:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 14:22:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 8589] New: Wrong atomic intrinsic codegen at -O0
Message-ID: <bug-8589-206@http.llvm.org/bugs/>

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

           Summary: Wrong atomic intrinsic codegen at -O0
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running "llc -O1" (or higher -O level) on the attached testcase results in
correct code.  But with "llc -O0", an atomic operation is reordered wrongly:

  call void @GOMP_loop_end_nowait() nounwind
  %13 = getelementptr inbounds i8* %.omp_data_i, i64 8
  %14 = bitcast i8* %13 to i32*
  call void @llvm.memory.barrier(i1 true, i1 true, i1 true, i1 true, i1 true)
  %15 = call i32 @llvm.atomic.load.and.i32.p0i32(i32* %14, i32 %12)
  call void @llvm.memory.barrier(i1 true, i1 true, i1 true, i1 true, i1 true)

->

        lock
        cmpxchgl        %ecx, (%rsi)
        movl    %eax, (%rsp)            # 4-byte Spill
        jne     .LBB0_6
# BB#7:                                 # %6
        callq   GOMP_loop_end_nowait
        movabsq $8, %rax
        movq    88(%rsp), %rcx          # 8-byte Reload
        addq    %rcx, %rax
        mfence
        mfence

There are several crazy things here.  First off, the atomic operation has
been moved before the call to GOMP_loop_end_nowait, which is just wrong
since it writes to memory that is manipulated by GOMP_loop_end_nowait.
It has also been moved out from between the memory barriers (leaving the
two lonely "mfence" instructions with the atomic no longer between 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 Nov 11 17:10:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 17:10:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 5272] analyzer false positive on access to casted
 hard-coded address
In-Reply-To: <bug-5272-206@http.llvm.org/bugs/>
References: <bug-5272-206@http.llvm.org/bugs/>
Message-ID: <20101111231042.B56782A6C12C@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #1 from Ted Kremenek <kremenek at apple.com> 2010-11-11 17:10:42 CST ---
Fixed here:

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

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

From bugzilla-daemon at llvm.org  Thu Nov 11 17:36:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 17:36:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 8590] New: Bogus warning about null pointer deref
 when inner loop exit can prove outer loop exits
Message-ID: <bug-8590-206@http.llvm.org/bugs/>

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

           Summary: Bogus warning about null pointer deref when inner loop
                    exit can prove outer loop exits
           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: tjw at omnigroup.com
                CC: llvmbugs at cs.uiuc.edu


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

In the attached test case, the exit path for the inner loop sets up state such
that the outer loop must exit before the 'cursor' can be assigned NULL.  Clang
doesn't seem to realize this.

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

From bugzilla-daemon at llvm.org  Thu Nov 11 21:34:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 21:34:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 8342] Direct-initialization of class object in
 second step of copy-initialization fails for explicit copy-constructor.
In-Reply-To: <bug-8342-206@http.llvm.org/bugs/>
References: <bug-8342-206@http.llvm.org/bugs/>
Message-ID: <20101112033433.256E32A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-11 21:34:32 CST ---
Fixed in Clang r118880.

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

From bugzilla-daemon at llvm.org  Thu Nov 11 22:20:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 22:20:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8591] New: Initializer lists not supported
Message-ID: <bug-8591-206@http.llvm.org/bugs/>

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

           Summary: Initializer lists not supported
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


int foo(int a) {
  return { a };
}

With g++:

test.cc:2:3: warning: extended initializer lists only available with -std=c++0x
or -std=gnu++0x

With clang:

test.cc:2:10: error: expected expression
  return { a };

I wonder how hard it is to implement at least the very basic cases.

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

From bugzilla-daemon at llvm.org  Thu Nov 11 22:39:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 22:39:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 8498] Assertion failure in template instantiation.
In-Reply-To: <bug-8498-206@http.llvm.org/bugs/>
References: <bug-8498-206@http.llvm.org/bugs/>
Message-ID: <20101112043913.D5C412A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-11 22:39:12 CST ---
This works for me in r118878.

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

From bugzilla-daemon at llvm.org  Thu Nov 11 22:46:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 22:46:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 4985] GNU Extension: Conditional expr with omitted
 middle operand is not treated as an lvalue
In-Reply-To: <bug-4985-206@http.llvm.org/bugs/>
References: <bug-4985-206@http.llvm.org/bugs/>
Message-ID: <20101112044610.DFC242A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-11-11 22:46:10 CST ---
This has already been implemented on 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  Thu Nov 11 22:49:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 22:49:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 8167] Invalid template code accepted
In-Reply-To: <bug-8167-206@http.llvm.org/bugs/>
References: <bug-8167-206@http.llvm.org/bugs/>
Message-ID: <20101112044923.2136E2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-11 22:49:22 CST ---
t3.cpp:1:16: error: expected ',' or '>' in template-parameter-list
template < int 0 ;
               ^

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

From bugzilla-daemon at llvm.org  Thu Nov 11 22:54:02 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 22:54:02 -0600 (CST)
Subject: [LLVMbugs] [Bug 8416] Assert: Declaration context must already be
	complete!
In-Reply-To: <bug-8416-206@http.llvm.org/bugs/>
References: <bug-8416-206@http.llvm.org/bugs/>
Message-ID: <20101112045402.F2DB82A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-11-11 22:54:02 CST ---
I can't reproduce either. Closing.

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

From bugzilla-daemon at llvm.org  Thu Nov 11 23:02:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 11 Nov 2010 23:02:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 8592] New: error: invalid instruction mnemonic
	'lretq'
Message-ID: <bug-8592-206@http.llvm.org/bugs/>

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

           Summary: error: invalid instruction mnemonic 'lretq'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: santosh.nagarakatte at gmail.com
                CC: llvmbugs at cs.uiuc.edu


While compiling the bitvisor-1.1, a hypervisor, I am encountering the following
error with clang

callrealmode.c:62:3: error: invalid instruction mnemonic 'lretq'
               "push %%rax\n"
               ^
<inline asm>:20:1: note: instantiated into assembly here
lretq
^
callrealmode.c:62:3: error: warning: ignoring directive for now
               "push %%rax\n"
               ^
<inline asm>:21:1: note: instantiated into assembly here
.code32
^
callrealmode.c:62:3: error: instruction requires a CPU feature not
currently enabled
               "push %%rax\n"

I have attached the callrealmode.i

The commandline to produce the error is below. the error occurs when the
integrated assembler of clang is invoked.

clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name
callrealmode.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -disable-red-zone -target-cpu x86-64
-target-feature -sse -target-linker-version 2.20.51 -v -g -nostdinc
-resource-dir
/home/santoshn/llvm/llvm-svn-obj/Debug+Asserts/bin/../lib/clang/2.9 -O2 -Wall
-ferror-limit 19 -fmessage-length 157 -fno-builtin -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o callrealmode.s -x cpp-output
callrealmode.i


clang -cc1as -triple x86_64-unknown-linux-gnu -filetype obj -o callrealmode.o
callrealmode.s

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

From bugzilla-daemon at llvm.org  Fri Nov 12 00:41:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 00:41:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 8593] New: loop-unroll and unroll-count options do
 not work unless loop-rotate option is passed
Message-ID: <bug-8593-206@http.llvm.org/bugs/>

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

           Summary: loop-unroll and unroll-count options do not work
                    unless loop-rotate option is passed
           Product: tools
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: opt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xuanji at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I compiled a simple program to llvm bitcode and attempted to use opt to unroll
the loop. I need to unroll loops 

#include <stdlib.h>

int main() {

  int a = 10;

  int i, count;
  for (i=0; i<a; i++)
    count += i;

  return count;

}

The command 
opt --loop-unroll --unroll-count 5 nl.bc 
does not unroll the loop wheares the command 
opt --loop-rotate --loop-unroll --unroll-count 5 nl.bc

does. Even in llvm-2.8/lib/Transforms/Utils/LoopUnroll.cpp there is a line
saying
// The loop-rotate pass can be helpful to avoid this in many cases.

LoopUnroll.cpp should be fixed so that the loop unrolling functionality works
on the loop in the program 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  Fri Nov 12 02:19:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 02:19:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 7248] Assert on "Identifier nested-name-specifier
 with no prefix or object type" failed
In-Reply-To: <bug-7248-206@http.llvm.org/bugs/>
References: <bug-7248-206@http.llvm.org/bugs/>
Message-ID: <20101112081934.8C0AF2A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #4 from John McCall <rjmccall at apple.com> 2010-11-12 02:19:33 CST ---
Fixed in r118887.

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

From bugzilla-daemon at llvm.org  Fri Nov 12 06:12:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 06:12:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 8594] New: Integrated assembler doesn't like
 ".section .note.GNU-stack, "", %progbits"
Message-ID: <bug-8594-206@http.llvm.org/bugs/>

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

           Summary: Integrated assembler doesn't like ".section
                    .note.GNU-stack,"",%progbits"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu


The following fails to build on Linux with the integrated assembler (Clang
built from trunk, r118889):

.globl icudt42_dat
        .section .note.GNU-stack,"",%progbits
        .section .rodata
        .align 8
        .type icudt42_dat,%object

$ clang -c a.s
a.s:2:37: error: expected the type
        .section .note.GNU-stack,"",%progbits
                                    ^
a.s:5:27: error: expected '@' before type
        .type icudt42_dat,%object

But it works with gcc (Ubuntu 4.4.3-4ubuntu5). Passing -no-integrated-as to
Clang also works.

(This blocks the Chromium/Clang build on Linux. The real .s file is here:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s)

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

From bugzilla-daemon at llvm.org  Fri Nov 12 11:41:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 11:41:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 8592] error: invalid instruction mnemonic 'lretq'
In-Reply-To: <bug-8592-206@http.llvm.org/bugs/>
References: <bug-8592-206@http.llvm.org/bugs/>
Message-ID: <20101112174142.547C82A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-11-12 11:41:41 CST ---
Fixed in r118903, thanks!

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

From bugzilla-daemon at llvm.org  Fri Nov 12 11:56:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 11:56:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 5643] CHECK-NOT should be more flexible
In-Reply-To: <bug-5643-206@http.llvm.org/bugs/>
References: <bug-5643-206@http.llvm.org/bugs/>
Message-ID: <20101112175637.E2A112A6C12C@llvm.org>

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

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> 2010-11-12 11:56:37 CST ---
Fixed in r 116592.

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

From bugzilla-daemon at llvm.org  Fri Nov 12 11:58:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 11:58:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 8287] Scheduling takes a very long time
In-Reply-To: <bug-8287-206@http.llvm.org/bugs/>
References: <bug-8287-206@http.llvm.org/bugs/>
Message-ID: <20101112175813.BCE962A6C124@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #1 from Andrew Trick <atrick at apple.com> 2010-11-12 11:58:12 CST ---
There is a much larger issue here in the frontend. If you can reproduce
anything close to this with clang or llvm-gcc, please file a new bug with the C
source (the IR test case of this bug is the output produced by a frontend bug).

Meanwhile, I did commit fix r118904 and test case r118906 for the compile time
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 Nov 12 12:13:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 12:13:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 8594] Integrated assembler doesn't like ".section
 .note.GNU-stack, "", %progbits"
In-Reply-To: <bug-8594-206@http.llvm.org/bugs/>
References: <bug-8594-206@http.llvm.org/bugs/>
Message-ID: <20101112181326.BFBD52A6C12F@llvm.org>

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

Jeffrey Yasskin <jyasskin at google.com> changed:

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

--- Comment #3 from Jeffrey Yasskin <jyasskin at google.com> 2010-11-12 12:13:26 CST ---
Rafael says this was fixed by r118893.

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

From bugzilla-daemon at llvm.org  Fri Nov 12 12:44:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 12:44:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 8592] error: invalid instruction mnemonic 'lretq'
In-Reply-To: <bug-8592-206@http.llvm.org/bugs/>
References: <bug-8592-206@http.llvm.org/bugs/>
Message-ID: <20101112184456.C0B482A6C124@llvm.org>

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

Santosh <santosh.nagarakatte at gmail.com> changed:

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

--- Comment #3 from Santosh <santosh.nagarakatte at gmail.com> 2010-11-12 12:44:56 CST ---
The bug still persists in the revision 118906. lretl is the instruction causing
problems.

I have attached callrealmode.i file

cc1 commandline is below

clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name
callrealmode.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -disable-red-zone -target-cpu x86-64
-target-feature -sse -target-linker-version 2.20.51 -v -g -nostdinc
-resource-dir
/home/santoshn/llvm/llvm-svn-obj/Debug+Asserts/bin/../lib/clang/2.9 -O2 -Wall
-ferror-limit 19 -fmessage-length 156 -fno-builtin -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o callrealmode.s -x cpp-output
callrealmode.i

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

From bugzilla-daemon at llvm.org  Fri Nov 12 12:55:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 12:55:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 8592] error: invalid instruction mnemonic 'lretq'
In-Reply-To: <bug-8592-206@http.llvm.org/bugs/>
References: <bug-8592-206@http.llvm.org/bugs/>
Message-ID: <20101112185518.7327D2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-11-12 12:55:17 CST ---
Ok, you didn't say anything about lretl.  :)  Fixed in r118916.  Please open
new bugs for new issues.

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

From bugzilla-daemon at llvm.org  Fri Nov 12 13:17:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 13:17:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 8595] New: error:instruction requires a CPU feature
 not currently enabled for pusha, popa, .code32, .code64, 
Message-ID: <bug-8595-206@http.llvm.org/bugs/>

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

           Summary: error:instruction requires a CPU feature not currently
                    enabled for pusha, popa, .code32, .code64,
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: santosh.nagarakatte at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5764)
 --> (http://llvm.org/bugs/attachment.cgi?id=5764)
.i file with popa pusha .cod32 .code64 causing the problem

I am compiling bitvisor-1.1 with clang. While compiling the attached file
callrealmode.i, I am getting the following errors.

callrealmode.c:62:3: error: instruction requires a CPU feature not currently
enabled
                "push %%rax\n"
                ^
<inline asm>:30:1: note: instantiated into assembly here
pusha


callrealmode.c:62:3: error: warning: ignoring directive for now
                "push %%rax\n"
                ^
<inline asm>:40:1: note: instantiated into assembly here
.code64

callrealmode.c:62:3: error: instruction requires a CPU feature not currently
enabled
                "push %%rax\n"
                ^
<inline asm>:32:1: note: instantiated into assembly here
popa
^

The -cc1 commandline is below

clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name
callrealmode.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -disable-red-zone -target-cpu x86-64
-target-feature -sse -target-linker-version 2.20.51 -v -g -nostdinc
-resource-dir
/home/santoshn/llvm/llvm-svn-obj/Debug+Asserts/bin/../lib/clang/2.9 -O2 -Wall
-ferror-limit 19 -fmessage-length 166 -fno-builtin -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o callrealmode.s -x cpp-output
callrealmode.i

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

From bugzilla-daemon at llvm.org  Fri Nov 12 16:55:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 16:55:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 8596] New: MC Temporary Symbol Name Clash
Message-ID: <bug-8596-206@http.llvm.org/bugs/>

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

           Summary: MC Temporary Symbol Name Clash
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pdox at google.com
                CC: llvmbugs at cs.uiuc.edu


Both CodeGen and MCAsmParser use MCContext::CreateTempSymbol() to create a
unique temporary symbol. The symbol is made unique by incrementing a UniqueID
counter.

But if the output of CodeGen is first emitted to a .s file, and then afterwards
assembled by llvm-mc, the UniqueID counter is not preserved, so naming clashes
can occur.

On X86-64 Linux ELF, you can demonstrate the problem using conflict.ll:

llc -filetype=asm conflict.ll -o conflict.s
llvm-mc -filetype=obj conflict.s -o conflict.o

The error:

conflict.s:23:1: error: invalid symbol redefinition
.Ltmp0:
^

Reason:
In llvm-mc, the "." expression is evaluated by creating a temporary symbol, but
the temporary name .Ltmp0 is already taken, since it was generated during the
call to llc.

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

From bugzilla-daemon at llvm.org  Fri Nov 12 17:45:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 17:45:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 8130] Clang fails to partially order overloaded
 operators correctly
In-Reply-To: <bug-8130-206@http.llvm.org/bugs/>
References: <bug-8130-206@http.llvm.org/bugs/>
Message-ID: <20101112234529.89B162A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-12 17:45:29 CST ---
Fixed in Clang r118944.

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

From bugzilla-daemon at llvm.org  Fri Nov 12 18:09:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 12 Nov 2010 18:09:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 8597] New: clang doesn't report implicit 64->32
 cast as it should with -Wshorten-64-to-32
Message-ID: <bug-8597-206@http.llvm.org/bugs/>

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

           Summary: clang doesn't report implicit 64->32 cast as it should
                    with -Wshorten-64-to-32
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tjw at omnigroup.com
                CC: llvmbugs at cs.uiuc.edu


In the attached test case, when building for i386, the following line doesn't
produce a warning with clang:

    return NSMakePoint(v.x/length, v.y/length);

where length is a double.

llvm-gcc-4.2 does warn 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  Sat Nov 13 08:35:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 08:35:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 8410] Assertion failes in SFINAE expression: Unable
 to find instantiation of declaration!
In-Reply-To: <bug-8410-206@http.llvm.org/bugs/>
References: <bug-8410-206@http.llvm.org/bugs/>
Message-ID: <20101113143541.D201D2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-13 08:35:41 CST ---
This is working for me now. I believe I fixed it yesterday as part of another
bug fix.

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

From bugzilla-daemon at llvm.org  Sat Nov 13 08:55:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 08:55:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 2965] Bogus format string warning
In-Reply-To: <bug-2965-206@http.llvm.org/bugs/>
References: <bug-2965-206@http.llvm.org/bugs/>
Message-ID: <20101113145524.BE9E12A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #7 from Douglas Gregor <dgregor at apple.com> 2010-11-13 08:55:23 CST ---
This is correct behavior. The global variable

  static const char *zFormat1 = "%4d %-13s %4d %4d %4d %-4s %.2X %s\n";

can be reassigned, which is a potential security problem. As noted in the
comments, add 'const' and the security problem (along with the warning) 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  Sat Nov 13 09:06:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 09:06:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 4555] protocol-qualified-Class not supported by
	clang yet
In-Reply-To: <bug-4555-206@http.llvm.org/bugs/>
References: <bug-4555-206@http.llvm.org/bugs/>
Message-ID: <20101113150611.A906D2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-11-13 09:06:10 CST ---
This seems to be working fine 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  Sat Nov 13 09:08:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 09:08:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 4576] clang-cc -ast-dump crashes
In-Reply-To: <bug-4576-206@http.llvm.org/bugs/>
References: <bug-4576-206@http.llvm.org/bugs/>
Message-ID: <20101113150853.872B02A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-11-13 09:08:52 CST ---
This is working fine 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  Sat Nov 13 09:12:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 09:12:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 4799] Missing warning for integer overflows
In-Reply-To: <bug-4799-206@http.llvm.org/bugs/>
References: <bug-4799-206@http.llvm.org/bugs/>
Message-ID: <20101113151252.5ACE02A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2010-11-13 09:12:51 CST ---
We have this warning now:


t.c:3:13: warning: implicit conversion from 'unsigned long long' to 'int'
      changes value from 4294967296 to 0 [-Wconstant-conversion]
    int x = 4294967296ULL;
        ~   ^~~~~~~~~~~~~

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

From bugzilla-daemon at llvm.org  Sat Nov 13 09:32:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 09:32:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 5365] __attribute__ ((__transparent_union__))
 implementation is incomplete
In-Reply-To: <bug-5365-206@http.llvm.org/bugs/>
References: <bug-5365-206@http.llvm.org/bugs/>
Message-ID: <20101113153228.0A26D2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-11-13 09:32:26 CST ---
This is fixed in top-of-tree.

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

From bugzilla-daemon at llvm.org  Sat Nov 13 09:41:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 09:41:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 5372] Warning in tools/CIndex/CIndex.cpp about
 tmpnam() being unsafe.
In-Reply-To: <bug-5372-206@http.llvm.org/bugs/>
References: <bug-5372-206@http.llvm.org/bugs/>
Message-ID: <20101113154115.B88ED2A6C12D@llvm.org>

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

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> 2010-11-13 09:41:15 CST ---
The uses of tmpnam are gone.

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

From bugzilla-daemon at llvm.org  Sat Nov 13 09:50:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 09:50:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 8598] New: Failed template argument deduction
 involving member function pointers
Message-ID: <bug-8598-206@http.llvm.org/bugs/>

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

           Summary: Failed template argument deduction involving member
                    function pointers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


jhelom:clang dgregor$ cat t.cpp 
    template<class T> struct identity { typedef T type; };

    template<class T, class C>
    void f(T C::*, typename identity<T>::type*){}

    struct X { void f() {}; };

    int main() { f(&X::f, 0); }


jhelom:clang dgregor$ clang++ t.cpp 
t.cpp:8:18: error: no matching function for call to 'f'
    int main() { f(&X::f, 0); }
                 ^
t.cpp:4:10: note: candidate template ignored: failed template argument
deduction
    void f(T C::*, typename identity<T>::type*){}
         ^


(This is from core issue 1184)

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

From bugzilla-daemon at llvm.org  Sat Nov 13 10:45:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 10:45:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 8334] Wrong template parameter is used for default
 copy constructor of template class
In-Reply-To: <bug-8334-206@http.llvm.org/bugs/>
References: <bug-8334-206@http.llvm.org/bugs/>
Message-ID: <20101113164509.1E1822A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2010-11-13 10:45:08 CST ---
Clang is behaving correctly. The STL implementation is rebinding the allocator
based on the value type of the list, which is correct. GCC does the same thing.

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

From bugzilla-daemon at llvm.org  Sat Nov 13 13:37:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 13:37:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 8425] clang rejects valid implicit conversion
 sequence in templates
In-Reply-To: <bug-8425-206@http.llvm.org/bugs/>
References: <bug-8425-206@http.llvm.org/bugs/>
Message-ID: <20101113193716.32E652A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-11-13 13:37:15 CST ---
Fixed in Clang r119005.

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

From bugzilla-daemon at llvm.org  Sat Nov 13 13:39:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 13:39:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 8481] TemplateDeductionResult triggers an assertion
	at line 464
In-Reply-To: <bug-8481-206@http.llvm.org/bugs/>
References: <bug-8481-206@http.llvm.org/bugs/>
Message-ID: <20101113193951.118612A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2010-11-13 13:39:50 CST ---
This is working fine on trunk. If you're still running into problems, please
provide preprocessed input.

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

From bugzilla-daemon at llvm.org  Sat Nov 13 20:18:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 20:18:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 8599] New: poor "invalid type name" error for
 c99/c++ for loop typo
Message-ID: <bug-8599-206@http.llvm.org/bugs/>

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

           Summary: poor "invalid type name" error for c99/c++ for loop
                    typo
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


On this code:
int f() {
    for (intt i = 1; i < 10; i++)
        ;
}

We produce:


t.c:3:7: error: use of undeclared identifier 'intt'; did you mean 'int'?
        for (intt i = 1; i < 10; i++)
             ^
t.c:3:19: error: use of undeclared identifier 'i'
        for (intt i = 1; i < 10; i++)
                         ^
t.c:3:27: error: use of undeclared identifier 'i'
        for (intt i = 1; i < 10; i++)
                                 ^

It would be nice to generate "unknown type name 'intt'" style errors,
recovering correctly.

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

From bugzilla-daemon at llvm.org  Sat Nov 13 22:29:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 22:29:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 8334] Wrong template parameter is used for default
 copy constructor of template class
In-Reply-To: <bug-8334-206@http.llvm.org/bugs/>
References: <bug-8334-206@http.llvm.org/bugs/>
Message-ID: <20101114042944.9BEA12A6C124@llvm.org>

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

Yuri <yuri at tsoft.com> changed:

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

--- Comment #5 from Yuri <yuri at tsoft.com> 2010-11-13 22:29:44 CST ---
This testcase fails in clang++ and succeeds in gcc. You are saying that they
both do the same thing. This doesn't make sense.

Possible solutions can be:
1. gcc and clang++ both succeed or both fail for me, then please provide
versions of both.
2. gcc is wrong and clang++ is right, please explain why.
3. bug is fixed in clang++.

This case is taken from the working project that only compiles under gcc and
not 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 Nov 13 23:38:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 13 Nov 2010 23:38:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 8597] clang doesn't report implicit 64->32 cast as
 it should with -Wshorten-64-to-32
In-Reply-To: <bug-8597-206@http.llvm.org/bugs/>
References: <bug-8597-206@http.llvm.org/bugs/>
Message-ID: <20101114053820.6556C2A6C12D@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-11-13 23:38:20 CST ---
The warning you want is -Wconversion.  -Wshorten-64-to-32 is strictly a
portability aid and should not be warning about arbitrary implicit narrowings
just because of their byte size.

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

From bugzilla-daemon at llvm.org  Sun Nov 14 01:51:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Nov 2010 01:51:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 8600] New: Crash on
	ExecutionEngine::addGlobalMapping()
Message-ID: <bug-8600-206@http.llvm.org/bugs/>

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

           Summary: Crash on ExecutionEngine::addGlobalMapping()
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mpnk121 at live.com
                CC: llvmbugs at cs.uiuc.edu


On MSVC 2008 I get a crash with while calling ExecutionEngine::addGlobalMapping
(as seen below), in 2.7, 2.8 and trunk.
It throws an unhandled exception (an access violation) seemingly at
MutexImpl::acquire().

Reduced test case:

void foo() { }
int main() {
  ExecutionEngine *jitengine =
EngineBuilder(jitmodule).setEngineKind(EngineKind::JIT).create();
  Function *func = Function::Create(TypeBuilder<void(),
false>::get(getGlobalContext()), GlobalValue::ExternalLinkage, "foo");
  jitengine->addGlobalMapping(func, (void*)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 Nov 14 14:56:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Nov 2010 14:56:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 8601] New: poor location information for 'invalid
 const' diagnostic
Message-ID: <bug-8601-206@http.llvm.org/bugs/>

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

           Summary: poor location information for 'invalid const'
                    diagnostic
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I got this today:


ARMMCInstLower.cpp:29:18: error: type qualifier is not allowed on this function
static MCOperand GetSymbolRef(const MachineOperand &MO, const MCSymbol *Symbol,
                 ^

This made my scratch my head and wonder what clang was talking about.  It turns
out that I defined the function as:

static MCOperand GetSymbolRef(const MachineOperand &MO, const MCSymbol *Symbol,
                              AsmPrinter &Printer) const {


The diagnostic should point at the 'const', not at the symbol name.  Bonus
points for saying "'const' type qualifier is not allowed on this function".

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

From bugzilla-daemon at llvm.org  Sun Nov 14 16:13:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Nov 2010 16:13:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 8602] New: Assertion
 `!cast<StoreInst>(Use)->isVolatile() && "AST broken"' failed.
Message-ID: <bug-8602-206@http.llvm.org/bugs/>

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

           Summary: Assertion `!cast<StoreInst>(Use)->isVolatile() && "AST
                    broken"' 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/tmp338$ clang -v

clang version 2.9 (trunk 119082)
Target: i386-pc-linux-gnu
Thread model: posix

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

clang: LICM.cpp:695: void<unnamed>::LICM::PromoteAliasSet(llvm::AliasSet&):
Assertion `!cast<StoreInst>(Use)->isVolatile() && "AST broken"' failed.
0  clang 0x093cde58
Stack dump:
0.    Program arguments:
/mnt/z/z/compiler-install/llvm-gcc-r119082-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 -resource-dir
/mnt/z/z/compiler-install/llvm-gcc-r119082-install/bin/../lib/clang/2.9 -O2 -w
-ferror-limit 19 -fmessage-length 80 -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 'Loop Pass Manager' on function '@nt320'
5.    Running pass 'Loop Invariant Code Motion' on basic block '%for.body'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

regehr at home:~/volatile/bugs/tmp338$ cat small.c

volatile unsigned long long g_10;

int *volatile g_17[4][1][1][5][1][5] = {
};

int g_45;
int g_46;
int g_47;
int g_48[9][7] = {
};

void nt320 (int * p_41, int * p_42, int * p_43)
{
  int l_44 = 0;
  for (0; 1; g_47 += 1)
    g_17[l_44][g_10][g_45][g_46][g_47][g_48[1][5]] = &g_47;
}

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

From bugzilla-daemon at llvm.org  Sun Nov 14 21:30:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Nov 2010 21:30:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 8113] MachineMemOperands not propageted in
 ARMLoadStoreOptimizer.cpp
In-Reply-To: <bug-8113-206@http.llvm.org/bugs/>
References: <bug-8113-206@http.llvm.org/bugs/>
Message-ID: <20101115033041.C1A2A2A6C12D@llvm.org>

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

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

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

--- Comment #2 from Evan Cheng <evan.cheng at apple.com> 2010-11-14 21:30:40 CST ---
Fixed: r119109.

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

From bugzilla-daemon at llvm.org  Sun Nov 14 21:35:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Nov 2010 21:35:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 8603] New: Invalid assembly accepted on ELF
Message-ID: <bug-8603-206@http.llvm.org/bugs/>

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

           Summary: Invalid assembly accepted on ELF
           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


ELF cannot handle relocations like


.Lsym2:
        .section foo, "", @progbits
        .Lsym3:
.Lsym4 = .Lsym2 - .Lsym3
        .long    .Lsym4


We should reject 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  Sun Nov 14 22:04:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Nov 2010 22:04:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 8604] New: Assertion `(unsigned)FI-LowSpillSlot <
 SpillSlotToUsesMap.size() && "Invalid spill slot"' failed.
Message-ID: <bug-8604-206@http.llvm.org/bugs/>

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

           Summary: Assertion `(unsigned)FI-LowSpillSlot <
                    SpillSlotToUsesMap.size() && "Invalid spill slot"'
                    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


Sorry for the horrendous test case, our reducer got stuck here.

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

clang version 2.9 (trunk 119082)
Target: i386-pc-linux-gnu
Thread model: posix

regehr at home:~/volatile/bugs/tmp339$ clang -O3 -c -w -fomit-frame-pointer
small.c

clang: VirtRegMap.cpp:180: void llvm::VirtRegMap::addSpillSlotUse(int,
llvm::MachineInstr*): Assertion `(unsigned)FI-LowSpillSlot <
SpillSlotToUsesMap.size() && "Invalid spill slot"' failed.
0  clang 0x093cde58
Stack dump:
0.    Program arguments:
/mnt/z/z/compiler-install/llvm-gcc-r119082-install/bin/clang -cc1 -triple
i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -masm-verbose -mconstructor-aliases -target-cpu
pentium4 -target-linker-version 2.20.51 -resource-dir
/mnt/z/z/compiler-install/llvm-gcc-r119082-install/bin/../lib/clang/2.9 -O3 -w
-ferror-limit 19 -fmessage-length 94 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o small.o -x c small.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'small.c'.
4.    Running pass 'Linear Scan Register Allocator' on function '@int321'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

regehr at home:~/volatile/bugs/tmp339$ cat small.c

extern void __assert_fail (__const char *__assertion, __const char *__file,
               unsigned int __line, __const char *__function)
  __attribute__ ((__)) __attribute__ ((__noreturn__));

static unsigned char
foo (signed char si1, unsigned char si2)
{
  return si1 - si2;
}

static unsigned char
bar (signed char left, unsigned int right)
{
  return left || right || left >> right ? left : left << right;
}

static unsigned char
baz (signed char left, unsigned int right)
{
  return left < 0 || right ? left : left >> right;
}

static unsigned char
bux (unsigned ui1, unsigned char ui2)
{
  return ui1 - ui2;
}

static unsigned long long
biz (unsigned long long ui1, unsigned long long ui2)
{
  return ui2 ? : (ui1 / ui2);
}

struct S0
{
  unsigned char f1;
};

struct S3
{
  signed f0:1;
};

struct S4
{
  volatile unsigned f8:1;
  const unsigned f9:1;
};

struct S5
{
  const unsigned char f0;
};

struct S6
{
  const struct S5 f2;
  struct S3 f3;
};

unsigned char g_20[7] = {
  0
};

struct S6 g_67[5][9][1][1] = {
};

struct S6 *g_66[1] = {
  &g_67[2][3][0][0]
};

struct S6 g_71[10][6] = {
};

struct S4 g_88 = {
  0
};

short *g_94 = &g_20[2];

struct S6 ***g_114[6] = {
  0
};

struct S4 g_173 = {
  0
};

struct S6 g_252 = {
  0x17D44FB6F4A190B2LL, {
             }
  , 0
};

struct S0 g_314 = {
};

struct S6 **g_335[5] = {
  &g_66[0], &g_66[0], &g_66[0], &g_66[0], &g_66[0]
};

unsigned char g_429[2] = {
  0
};

const short *g_428 = &g_429[0];

int func_78 (struct S6 ***const p_79, signed char p_80, unsigned p_81);

int321 (void)
{
  struct S6 *l_301;
  long long l_366;
  int i;
lbl_493:{
    struct S6 **l_327 = &l_301;
    struct S6 ***const l_326 = &l_327;
    func_78 (l_326, g_173.f8, 0) & g_429[0]
      && g_428 <= &g_429[1] ? : _fail ("", "rand005597.c",
                       __PRETTY_FUNCTION__);
  }
  unsigned char l_468 = 1;
  struct S6 *l_475[1];
  for (0; 1; l_366 = safe (l_366, 1))
    if (bux (bar (*g_94, 0), 0) | func_78 (&g_335[4], 1, 0))
      {
    unsigned char l_480[9];
    l_480[i] = 0;
    l_480[6] =
      biz (l_468,
           func_78) >= (func_82 (g_114[1], g_252.f2.f0,
                     l_475[0]) <= baz (foo (*g_94,
                                *g_428) > 0,
                               *g_428));
    &g_20[0]
      && g_94 <= &g_20[6] ? : __assert_fail ("", "rand005597.c", 757,
                         __PRETTY_FUNCTION__);
    if (g_314.f1)
      goto lbl_493;
      }
}

int
func_78 (struct S6 ***const p_79, signed char p_80, unsigned p_81)
{
  struct S6 ***l_90[3];
  unsigned char l_93 = func_82 (l_90[1], g_88.f9);
  return l_93;
}

int
func_82 (struct S6 ***p_83, struct S2 *const int32p_85, int p_86)
{
  return g_71[9][4].f3.f0;
}

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

From bugzilla-daemon at llvm.org  Sun Nov 14 23:42:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 14 Nov 2010 23:42:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 8334] Wrong template parameter is used for default
 copy constructor of template class
In-Reply-To: <bug-8334-206@http.llvm.org/bugs/>
References: <bug-8334-206@http.llvm.org/bugs/>
Message-ID: <20101115054244.353C52A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2010-11-14 23:42:43 CST ---
(In reply to comment #5)
> This testcase fails in clang++ and succeeds in gcc. You are saying that they
> both do the same thing. This doesn't make sense.
> 
> Possible solutions can be:
> 1. gcc and clang++ both succeed or both fail for me, then please provide
> versions of both.
> 2. gcc is wrong and clang++ is right, please explain why.
> 3. bug is fixed in clang++.
> 
> This case is taken from the working project that only compiles under gcc and
> not clang.

Both clang++ and g++ 4.2 reject this code in the same way, because there is no
suitable operator != for my_alloc instances. Clang and g++ both provide good
diagnostics, and the fix to your code is trivial. Just add:

    template<typename T1>
    bool operator!=(const my_alloc<T1> &other) const { return (this != &other);
} 

into the my_alloc class and it works with both compilers.

If you found some version of g++ that worked, it's probably because that
standard library version uses == rather than != on allocators.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 00:50:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 00:50:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 8179] [ocaml bindings] exception Failure("There are
 two interfaces of module Llvm_bitwriter.")
In-Reply-To: <bug-8179-206@http.llvm.org/bugs/>
References: <bug-8179-206@http.llvm.org/bugs/>
Message-ID: <20101115065026.EFE0D2A6C124@llvm.org>

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

ojab <ojab at ojab.ru> changed:

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

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

From bugzilla-daemon at llvm.org  Mon Nov 15 01:55:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 01:55:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 8605] New: Unsupported EmitRawText called on Windows
Message-ID: <bug-8605-206@http.llvm.org/bugs/>

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

           Summary: Unsupported EmitRawText called on Windows
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: davidagraf+clang at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Hello
I try to compile the open source project zorba (http://www.zorba-xquery.com/)
with clang on Windows. Unfortunately, I came across an internal clang error I
am not able to fix myself:

clang version 2.9 (trunk 119081)
Target: i686-pc-win32
Thread model: posix
 "C:/Users/sausalito/Desktop/zorba-devel/clang/build/bin/clang++.exe" -cc1
-triple i686-pc-win32 -em
it-obj -mrelax-all -disable-free -main-file-name errstrings.cpp
-mrelocation-model static -mdisable-
fp-elim -masm-verbose -mconstructor-aliases -v -g -resource-dir
C:/Users/sausalito/Desktop/zorba-dev
el/clang/build/bin/../lib/clang/2.9 -I
C:\Users\sausalito\Desktop\thirdparty\libxml2-2.7.7.win32\inc
lude -I C:\Users\sausalito\Desktop\thirdparty\curl\curl-7.21.1\include -I
C:\Users\sausalito\Desktop
\thirdparty\tidy-060405-dll\include -I
C:\Users\sausalito\Desktop\thirdparty\iconv-1.9.2.win32\inclu
de -I C:\Users\sausalito\Desktop\thirdparty\icu4c-4_4_1-src\icu\include -I
C:\Users\sausalito\Deskto
p\thirdparty\xerces-c-3.1.1\src -I
C:\Users\sausalito\Desktop\zorba-devel\build_clang\include -I C:\
Users\sausalito\Desktop\zorba-devel\trunk\include -I
C:\Users\sausalito\Desktop\zorba-devel\trunk\ex
ternal -ferror-limit 19 -fmessage-length 100 -fexceptions -fms-extensions
-fmsc-version=1300 -fgnu-r
untime -fdiagnostics-show-option -fcolor-diagnostics -o
CMakeFiles\json.dir\errstrings.obj -x c++ C:
\Users\sausalito\Desktop\zorba-devel\trunk\external\json\errstrings.cpp
clang -cc1 version 2.9 based upon llvm 2.9svn-r119080 hosted on i686-pc-win32
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 C:\Users\sausalito\Desktop\thirdparty\libxml2-2.7.7.win32\include
 C:\Users\sausalito\Desktop\thirdparty\curl\curl-7.21.1\include
 C:\Users\sausalito\Desktop\thirdparty\tidy-060405-dll\include
 C:\Users\sausalito\Desktop\thirdparty\iconv-1.9.2.win32\include
 C:\Users\sausalito\Desktop\thirdparty\icu4c-4_4_1-src\icu\include
 C:\Users\sausalito\Desktop\thirdparty\xerces-c-3.1.1\src
 C:\Users\sausalito\Desktop\zorba-devel\build_clang\include
 C:\Users\sausalito\Desktop\zorba-devel\trunk\include
 C:\Users\sausalito\Desktop\zorba-devel\trunk\external

C:/Users/sausalito/Desktop/zorba-devel/clang/build/bin/../lib/clang/2.9/include
 C:\Program Files\Microsoft Visual Studio 10.0\VC\include
 C:\Program Files\Microsoft SDKs\Windows\v7.0A\\include
End of search list.
EmitRawText called on an MCStreamer that doesn't support it,  something must
not be fully mc'ized
clang++: error: clang frontend command failed with exit code 3 (use -v to see
invocation)

Do you know that problem? Is it fixable? Or by-passable?

Regards
David

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

From bugzilla-daemon at llvm.org  Mon Nov 15 03:04:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 03:04:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 8606] New: r119095 breaks sysroot on OS X and C++
	(at least)
Message-ID: <bug-8606-206@http.llvm.org/bugs/>

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

           Summary: r119095 breaks sysroot on OS X and C++ (at least)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


"r119095 01:05 - chandlerc
Make sysroot only apply to baked in paths which start with a '/'."

After this commit, trying to include C++ headers, I encounter the following
error:

[MacPro:~/Desktop] jddupas% clang++ -fsyntax-only -isysroot
/Developer/SDKs/MacOSX10.6.sdk test.cpp
In file included from test.cpp:2:
In file included from
/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/new:44:
/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/cstddef:49:10: fatal
error: 'bits/c++config.h' file not found

Tested with clang r119135.
"test.cpp" contains only a "#include <new>" directive.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 03:34:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 03:34:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 8606] r119095 breaks sysroot on OS X and C++ (at
	least)
In-Reply-To: <bug-8606-206@http.llvm.org/bugs/>
References: <bug-8606-206@http.llvm.org/bugs/>
Message-ID: <20101115093440.CB9FF2A6C12D@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #3 from Chandler Carruth <chandlerc at gmail.com> 2010-11-15 03:34:40 CST ---
Doh! Sorry for the breakage. I reproduced locally and r119139 should fix this.
Please re-open if you hit any other issues w/ isysroot!

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

From bugzilla-daemon at llvm.org  Mon Nov 15 08:41:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 08:41:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8565] llvm-mc cannot parse gcc output
In-Reply-To: <bug-8565-206@http.llvm.org/bugs/>
References: <bug-8565-206@http.llvm.org/bugs/>
Message-ID: <20101115144136.07CEA2A6C124@llvm.org>

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

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

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

--- Comment #6 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-15 08:41:35 CST ---
Fixed in 119144.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 08:48:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 08:48:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 8607] New: "argument unused during compilation"
	warning unclear
Message-ID: <bug-8607-206@http.llvm.org/bugs/>

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

           Summary: "argument unused during compilation" warning unclear
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Our build system sometimes compiles files with "clang -O2 -O0 -c". When it does
so, clang produces this warning:

clang: warning: argument unused during compilation: '-O2'

There are a few things which could be improved here.
 * The warning is inaccurate, in a sense: the argument isn't unused so much as
overridden.
 * This is the sort of warning I'd expect to get if I combine -E with -O2, but
clang doesn't seem to warn for that.
 * We haven't specified -fno-diagnostics-show-option, so I'd expect for this
message to tell me how to turn this warning off.
 * This warning is not produced if the linker is being invoked (and indeed -O2
-O0 is passed to the linker in this case).
 * It's not always obvious what the command-line was.

I'd prefer something like this:

<command-line>:1:6: warning: argument '-O2' overridden by '-O0'
[-Qunused-arguments]
clang -O2 -c test.cpp -o test -O0 -g
      ^~~                     ~~~

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

From bugzilla-daemon at llvm.org  Mon Nov 15 08:57:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 08:57:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 8608] New: unheralded conversion to bool
Message-ID: <bug-8608-206@http.llvm.org/bugs/>

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

           Summary: unheralded conversion to bool
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Axel.Naumann at cern.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Hi,

compiling
$ cat expr.cxx:
bool& f(unsigned char& c) { return (bool&)c; }
$ clang -c expr.cxx

crashes:

clang: /build/llvm/src/tools/clang/lib/AST/../../include/clang/AST/Expr.h:2004:
void clang::CastExpr::CheckCastConsistency() const: Assertion
`!getType()->isBooleanType() && "unheralded conversion to bool"' failed.
0  clang           0x000000000140ad6f
1  clang           0x000000000140cfe2
2  libpthread.so.0 0x00007f158cb9bb40
3  libc.so.6       0x00007f158be99ba5 gsignal + 53
4  libc.so.6       0x00007f158be9d6b0 abort + 384
5  libc.so.6       0x00007f158be92a71 __assert_fail + 241
6  clang           0x0000000000c1f0ca
7  clang           0x000000000094eec5
clang::Sema::BuildCStyleCastExpr(clang::SourceLocation, clang::TypeSourceInfo*,
clang::SourceLocation, clang::Expr*) + 309
8  clang           0x00000000009717bb clang::Sema::ActOnCastExpr(clang::Scope*,
clang::SourceLocation, clang::OpaquePtr<clang::QualType>,
clang::SourceLocation, clang::Expr*) + 107
9  clang           0x0000000000867636
clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool,
clang::OpaquePtr<clang::QualType>, clang::OpaquePtr<clang::QualType>&,
clang::SourceLocation&) + 566
10 clang           0x0000000000863eaa clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::OpaquePtr<clang::QualType>) + 2522
11 clang           0x000000000086458a clang::Parser::ParseCastExpression(bool,
bool, clang::OpaquePtr<clang::QualType>) + 42
12 clang           0x000000000086535e
clang::Parser::ParseAssignmentExpression() + 30
13 clang           0x0000000000865839 clang::Parser::ParseExpression() + 9
14 clang           0x000000000083f4d8
clang::Parser::ParseReturnStatement(clang::AttributeList*) + 136
15 clang           0x000000000083fd3b
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 1051
16 clang           0x00000000008403d4
clang::Parser::ParseCompoundStatementBody(bool) + 404
17 clang           0x0000000000840a16
clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 118
18 clang           0x000000000084a245
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 357
19 clang           0x0000000000850ed4
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 1188
20 clang           0x0000000000849149
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AttributeList*, clang::AccessSpecifier) + 201
21 clang           0x0000000000849564
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*,
clang::AccessSpecifier) + 372
22 clang           0x000000000084b375
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList,
clang::Parser::ParsingDeclSpec*) + 1333
23 clang           0x000000000084b4c2
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 114
24 clang           0x000000000083380b clang::ParseAST(clang::Sema&, bool) + 139
25 clang           0x0000000000707eb4 clang::CodeGenAction::ExecuteAction() +
68
26 clang           0x0000000000602545
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
27 clang           0x00000000005e223c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
28 clang           0x00000000005da1d5 cc1_main(char const**, char const**, char
const*, void*) + 405
29 clang           0x00000000005e11c5 main + 4085
30 libc.so.6       0x00007f158be84d8e __libc_start_main + 254
31 clang           0x00000000005d8a09
Stack dump:
0.    Program arguments: /build/llvm/opt-inst/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
expr.cxx -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.51 -resource-dir /build/llvm/opt-inst/bin/../lib/clang/2.9 -ferror-limit
19 -fmessage-length 130 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o expr.o -x c++ expr.cxx 
1.    expr.cxx:1:44: current parser token ';'
2.    expr.cxx:1:27: parsing function body 'f'
3.    expr.cxx:1:27: in compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

yes, ugly code, but an ICE is still a bit harsh :-) Can you help?

Cheers, Axel.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 09:19:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 09:19:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 8609] New: SCEV not updated correctly?
Message-ID: <bug-8609-206@http.llvm.org/bugs/>

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

           Summary: SCEV not updated correctly?
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: grosser at fim.uni-passau.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5775)
 --> (http://llvm.org/bugs/attachment.cgi?id=5775)
Failing testcase (not yet reduced)

For the attached test case I get the correct values, if scalar-evolution is
executed in a separate program. However if it is scheduled right after -O1 it
says it cannot predict some backedge-taken counts.

$opt  -O1 /tmp/unpredictable_exit_count.ll | opt -scalar-evolution -analyze 
[...]
Loop %"4.i.i": backedge-taken count is 1023
Loop %"4.i.i": max backedge-taken count is 1023
Loop %"3.i.i": backedge-taken count is 1023
Loop %"3.i.i": max backedge-taken count is 1023
[...]

$opt  -O1 /tmp/unpredictable_exit_count.ll -scalar-evolution -analyze 
[...]
Determining loop execution counts for: @main
Loop %"4.i.i": backedge-taken count is 1023
Loop %"4.i.i": max backedge-taken count is 1023
Loop %"3.i.i": Unpredictable backedge-taken count. 
Loop %"3.i.i": Unpredictable max backedge-taken count. 
[...]

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

From bugzilla-daemon at llvm.org  Mon Nov 15 09:29:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 09:29:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 8610] New: floating point exception support
Message-ID: <bug-8610-206@http.llvm.org/bugs/>

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

           Summary: floating point exception support
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Axel.Naumann at cern.ch
                CC: llvmbugs at cs.uiuc.edu


Hi,

attached file doesn't compile with
$ clang++ -c TUnixSystem.cxx
See output with -v below. GCC is happy with it. Is floating point exception
support available for Linux?

Cheers, Axel.


$ clang++ -v -c TUnixSystem.cxx 
clang version 2.9 (trunk 119140)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/build/llvm/opt-inst/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name TUnixSystem.cxx
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.20.51 -v
-resource-dir /build/llvm/opt-inst/bin/../lib/clang/2.9 -ferror-limit 19
-fmessage-length 114 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o TUnixSystem.o -x c++ TUnixSystem.cxx
clang -cc1 version 2.9 based upon llvm 2.9svn hosted on
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/usr/include/c++/4.4/i486-linux-gnu/64"
ignoring nonexistent directory "/usr/include/c++/4.3"
ignoring nonexistent directory "/usr/include/c++/4.3/x86_64-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/64"
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/arm-linux-gnueabi/"
ignoring nonexistent directory "/usr/include/c++/4.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.2"
ignoring nonexistent directory "/usr/include/c++/4.2/x86_64-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.2/backward"
ignoring nonexistent directory "/usr/include/c++/4.2"
ignoring nonexistent directory "/usr/include/c++/4.2/i486-linux-gnu/64"
ignoring nonexistent directory "/usr/include/c++/4.2/backward"
ignoring nonexistent directory "/usr/include/c++/4.1"
ignoring nonexistent directory "/usr/include/c++/4.1/x86_64-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.1/backward"
ignoring nonexistent directory "/usr/include/c++/4.1"
ignoring nonexistent directory "/usr/include/c++/4.1/i486-linux-gnu/64"
ignoring nonexistent directory "/usr/include/c++/4.1/backward"
ignoring nonexistent directory "/usr/include/c++/4.5.1/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.5.1/i686-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.4"
ignoring nonexistent directory "/usr/include/c++/4.4.4/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.4/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.4"
ignoring nonexistent directory "/usr/include/c++/4.4.4/i686-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.4/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.3"
ignoring nonexistent directory "/usr/include/c++/4.4.3/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.3"
ignoring nonexistent directory "/usr/include/c++/4.4.3/i686-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.2"
ignoring nonexistent directory "/usr/include/c++/4.4.2/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.2/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.1"
ignoring nonexistent directory "/usr/include/c++/4.4.1/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.1/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.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.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.0"
ignoring nonexistent directory "/usr/include/c++/4.3.0/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.3.0/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.1.2"
ignoring nonexistent directory "/usr/include/c++/4.1.2/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.1.2/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.4.3"
ignoring nonexistent directory "/usr/include/c++/4.4.3/x86_64-pc-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.4.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.3"
ignoring nonexistent directory "/usr/include/c++/4.4.3/i686-pc-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.4.3/backward"
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.4.3/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/g++-v4/i686-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/g++-v4/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/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 nonexistent directory "/usr/lib/llvm-gcc-4.2-9999/include/c++/4.2.1"
ignoring nonexistent directory
"/usr/lib/llvm-gcc-4.2-9999/include/c++/4.2.1/x86_64-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/llvm-gcc-4.2-9999/include/c++/4.2.1/backward"
ignoring duplicate directory "/usr/include/c++/4.4"
ignoring duplicate directory "/usr/include/c++/4.4/backward"
ignoring duplicate directory "/usr/include/c++/4.5.1"
ignoring duplicate directory "/usr/include/c++/4.5.1/backward"
ignoring duplicate directory "/usr/include/c++/4.4"
ignoring duplicate directory "/usr/include/c++/4.4/backward"
ignoring duplicate directory "/usr/include/c++/4.4"
ignoring duplicate directory "/usr/include/c++/4.4/backward"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.4
 /usr/include/c++/4.4/x86_64-linux-gnu
 /usr/include/c++/4.4/backward
 /usr/include/c++/4.5.1
 /usr/include/c++/4.5.1/backward
 /usr/local/include
 /build/llvm/opt-inst/bin/../lib/clang/2.9/include
 /usr/include
End of search list.
TUnixSystem.cxx:20:18: error: use of undeclared identifier 'FE_ALL_EXCEPT'
   feclearexcept(FE_ALL_EXCEPT);
                 ^
TUnixSystem.cxx:21:20: error: use of undeclared identifier 'feenableexcept'
   Int_t oldmask = feenableexcept(0);
                   ^
TUnixSystem.cxx:22:18: error: use of undeclared identifier 'FE_INVALID'
   if (oldmask & FE_INVALID  )   mask |= kInvalid;
                 ^
TUnixSystem.cxx:23:18: error: use of undeclared identifier 'FE_DIVBYZERO'
   if (oldmask & FE_DIVBYZERO)   mask |= kDivByZero;
                 ^
TUnixSystem.cxx:24:18: error: use of undeclared identifier 'FE_OVERFLOW'
   if (oldmask & FE_OVERFLOW )   mask |= kOverflow;
                 ^
TUnixSystem.cxx:25:18: error: use of undeclared identifier 'FE_UNDERFLOW'
   if (oldmask & FE_UNDERFLOW)   mask |= kUnderflow;
                 ^
TUnixSystem.cxx:26:18: error: use of undeclared identifier 'FE_INEXACT'
   if (oldmask & FE_INEXACT  )   mask |= kInexact;
                 ^
TUnixSystem.cxx:39:37: error: use of undeclared identifier 'FE_INVALID'
   if (mask & kInvalid  )   newm |= FE_INVALID;
                                    ^
TUnixSystem.cxx:40:37: error: use of undeclared identifier 'FE_DIVBYZERO'
   if (mask & kDivByZero)   newm |= FE_DIVBYZERO;
                                    ^
TUnixSystem.cxx:41:37: error: use of undeclared identifier 'FE_OVERFLOW'
   if (mask & kOverflow )   newm |= FE_OVERFLOW;
                                    ^
TUnixSystem.cxx:42:37: error: use of undeclared identifier 'FE_UNDERFLOW'
   if (mask & kUnderflow)   newm |= FE_UNDERFLOW;
                                    ^
TUnixSystem.cxx:43:37: error: use of undeclared identifier 'FE_INEXACT'
   if (mask & kInexact  )   newm |= FE_INEXACT;
                                    ^
TUnixSystem.cxx:44:18: error: use of undeclared identifier 'FE_ALL_EXCEPT'
   feclearexcept(FE_ALL_EXCEPT);
                 ^
TUnixSystem.cxx:45:20: error: use of undeclared identifier 'FE_ALL_EXCEPT'
   fedisableexcept(FE_ALL_EXCEPT);
                   ^
TUnixSystem.cxx:46:4: error: use of undeclared identifier 'feenableexcept'
   feenableexcept(newm);
   ^
15 errors generated.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 10:17:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 10:17:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 8611] New: linking and -g
Message-ID: <bug-8611-206@http.llvm.org/bugs/>

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

           Summary: linking and -g
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Axel.Naumann at cern.ch
                CC: llvmbugs at cs.uiuc.edu


Hi,

$ clang++ -v
clang version 2.9 (trunk 119140)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ cat t.cxx
void f() {}
$ clang++ -g -c t.cxx -fPIC
$ clang++ -g t.o -shared -olibt.so
clang: warning: argument unused during compilation: '-g'

while GCC is happy (and I believe actually requires -g for putting debug info
into the .so). Could you change that to be compatible with build systems using
GCC?

Cheers, Axel.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 10:44:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 10:44:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8612] New: Another regscavenger assertion
Message-ID: <bug-8612-206@http.llvm.org/bugs/>

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

           Summary: Another regscavenger assertion
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Consider the attached testcase. We have:

$ ./llc bugpoint-reduced-simplified.ll 
Assertion failed: ((!EarlyClobberRegs.test(Reg) ||
MI->isRegTiedToDefOperand(i)) && "Using an early clobbered register!"),
function forward, file
/Users/asl/Projects/llvm/src-git/lib/CodeGen/RegisterScavenging.cpp, line 205.
0  llc               0x000000010099bc99 PrintStackTrace(void*) + 38
1  llc               0x000000010099c254 SignalHandler(int) + 254
2  libSystem.B.dylib 0x00007fff84aec35a _sigtramp + 26
3  libSystem.B.dylib 0x000000010262e780 _sigtramp + 2108957760
4  llc               0x000000010002bca2 raise + 27

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

From bugzilla-daemon at llvm.org  Mon Nov 15 11:19:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 11:19:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 8613] New: Copy constructor of SwitchInst does not
 call SwitchInst::init
Message-ID: <bug-8613-206@http.llvm.org/bugs/>

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

           Summary: Copy constructor of SwitchInst does not call
                    SwitchInst::init
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kevin.streit at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


After calling the copy constructor of SwitchInst the newly created SwitchInst
is not fully initialized. In particular the ReservedSpace field is not
initialized which leads to undefined behavior when adding a case to the cloned
switch later.

The same holds for calling SwitchInst::clone_impl() since it just uses the copy
constructor.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 12:05:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 12:05:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8614] New: System include not found when #including
	<vector>
Message-ID: <bug-8614-206@http.llvm.org/bugs/>

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

           Summary: System include not found when #including <vector>
           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


When compiling a file that #includes <vector>, I'm getting

"/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/bits/stl_algobase.h:64:10:
fatal error: 'bits/c++config.h' file not found" with a trunk build when I
compile a file that includes <vector>

with r119131. This used to work fine with an older revision (r118190).

I'm on Snow Leopard, but I'm using the 10.5 SDK.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 12:22:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 12:22:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 8615] New: asmparser cant grok '
Message-ID: <bug-8615-206@http.llvm.org/bugs/>

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

           Summary: asmparser cant grok '
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes ~$ cat foo.s .set ASCII_BEL, '#' 
pes ~$ clang foo.s 
foo.s:1:17: error: invalid character in input 
.set ASCII_BEL, '#'                 
                ^ foo.s:1:17:
error: unknown token in expression
.set ASCII_BEL, '#'
                 ^
pes ~$ as foo.s
pes ~$

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

From bugzilla-daemon at llvm.org  Mon Nov 15 12:26:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 12:26:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 8616] New: gep+load/store is optimized differently
 that insertvalue+store and load+extractvalue.
Message-ID: <bug-8616-206@http.llvm.org/bugs/>

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

           Summary: gep+load/store is optimized differently that
                    insertvalue+store and load+extractvalue.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tom.prince at ualberta.net
                CC: llvmbugs at cs.uiuc.edu


I have attached to ll files, that differ simply in the use of GEP vs
insert/extractvalue.

For gep.ll, opt -O3 optimizes most of the code away, and running opt -O3 gets
rid of a single extra store.

For ev.ll, opt -O3 optimizes much less, but then running opt -O3 on the output
again gets rid of all the alloca.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 12:33:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 12:33:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 8611] linking and -g
In-Reply-To: <bug-8611-206@http.llvm.org/bugs/>
References: <bug-8611-206@http.llvm.org/bugs/>
Message-ID: <20101115183327.B0D1C2A6C12E@llvm.org>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-15 12:33:27 CST ---
Fixed in 119166.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 12:57:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 12:57:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 8614] System include not found when #including
	<vector>
In-Reply-To: <bug-8614-206@http.llvm.org/bugs/>
References: <bug-8614-206@http.llvm.org/bugs/>
Message-ID: <20101115185749.6599B2A6C12D@llvm.org>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #3 from Nico Weber <nicolasweber at gmx.de> 2010-11-15 12:57:48 CST ---
Works fine in r119171.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 13:34:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 13:34:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 8617] New: No warning for trivial cases of read of
 uninitialized variable
Message-ID: <bug-8617-206@http.llvm.org/bugs/>

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

           Summary: No warning for trivial cases of read of uninitialized
                    variable
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


This testcase produces no warnings:

  #include <iostream>
  int main() { int i; std::cout << i; }

This testcase also produces no warnings:

  #include <iostream>
  int main() { int i; if (i) return 1; }

g++ produces -Wuninitialized warnings for both of these.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 13:41:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 13:41:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 8618] New: compile error - syntax error when
 compiling Allocator.h
Message-ID: <bug-8618-206@http.llvm.org/bugs/>

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

           Summary: compile error - syntax error when compiling
                    Allocator.h
           Product: new-bugs
           Version: 2.8
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fred.bartholomai at efacec.com
                CC: llvmbugs at cs.uiuc.edu


Platform Red Hat Linux Enterprise 4.2
gcc: 3.2.3
Compiling llvm 2.8

Ran configure as instructed in the help web page
as followings:
configure --prefix=opt

in the "build" directory
ran make
and got the following error:

/home/freddyb/download/tar/llvm-2.8/include/llvm/Support/Allocator.h: In member
   function `T* llvm::SpecificBumpPtrAllocator<T>::Allocate(unsigned int)':
/home/freddyb/download/tar/llvm-2.8/include/llvm/Support/Allocator.h:215:
syntax
   error before `;' token
/home/freddyb/download/tar/llvm-2.8/include/llvm/Support/Allocator.h:216:
warning: no
   return statement in function returning non-void
In file included from
/home/freddyb/download/tar/llvm-2.8/lib/System/Host.cpp:20:
/home/freddyb/download/tar/llvm-2.8/lib/System/Unix/Host.inc: In function
   `std::string llvm::sys::getHostTriple()':
/home/freddyb/download/tar/llvm-2.8/lib/System/Unix/Host.inc:80: `isdigit'
   undeclared (first use this function)
/home/freddyb/download/tar/llvm-2.8/lib/System/Unix/Host.inc:80: (Each
   undeclared identifier is reported only once for each function it appears
   in.)
make[1]: *** [/home/freddyb/download/tar/llmv_build/lib/System/Release/Host.o]
Error 1
make[1]: Leaving directory `/home/freddyb/download/tar/llmv_build/lib/System'

Please advise. Any help would be appreciated.

I have following the install instructions to the letter.

Regards,

Fred B.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 14:49:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 14:49:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 8617] No warning for trivial cases of read of
 uninitialized variable
In-Reply-To: <bug-8617-206@http.llvm.org/bugs/>
References: <bug-8617-206@http.llvm.org/bugs/>
Message-ID: <20101115204907.8DC572A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2010-11-15 14:49:07 CST ---


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

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

From bugzilla-daemon at llvm.org  Mon Nov 15 14:56:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 14:56:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 8612] Another regscavenger assertion
In-Reply-To: <bug-8612-206@http.llvm.org/bugs/>
References: <bug-8612-206@http.llvm.org/bugs/>
Message-ID: <20101115205639.8464E2A6C12D@llvm.org>

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

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

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

--- Comment #4 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-11-15 14:56:39 CST ---
Fixed in r119183, 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 Nov 15 15:03:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 15:03:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 8618] compile error - syntax error when compiling
	Allocator.h
In-Reply-To: <bug-8618-206@http.llvm.org/bugs/>
References: <bug-8618-206@http.llvm.org/bugs/>
Message-ID: <20101115210337.26D3B2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-11-15 15:03:36 CST ---
The most likely issue is a bug in GCC 3.2, which is really really old.  Please
install a newer host compiler.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 15:33:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 15:33:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 8619] New: Assertion failed:
 (ConfluenceBlock->pred_size() == 2), function VisitConditionalOperator,
 file /Volumes/Data/g/clang/lib/Analysis/CFG.cpp, line 1207.
Message-ID: <bug-8619-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (ConfluenceBlock->pred_size() == 2),
                    function VisitConditionalOperator, file
                    /Volumes/Data/g/clang/lib/Analysis/CFG.cpp, line 1207.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


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

$ Release+Asserts/bin/clang -v
clang version 2.9 (trunk 119181)
Target: x86_64-apple-darwin10
Thread model: posix


$ Release+Asserts/bin/clang -O3 small.c 
small.c:3:19: warning: unknown attribute '__' ignored [-Wunknown-attributes]
  __attribute__ ((__)) __attribute__ ((__noreturn__));
                  ^
small.c:80:8: warning: incompatible pointer types initializing 'short *' with
an expression of type 'unsigned char *'
short *g_94 = &g_20[2];
       ^      ~~~~~~~~
small.c:93:5: warning: excess elements in struct initializer
  , 0
    ^
small.c:91:3: warning: implicit conversion from 'long long' to 'unsigned char'
changes value from 1717085005141872818 to 178 [-Wconstant-conversion]
  0x17D44FB6F4A190B2LL, {
  ^~~~~~~~~~~~~~~~~~~~
small.c:107:14: warning: incompatible pointer types initializing 'const short
*' with an expression of type 'unsigned char *'
const short *g_428 = &g_429[0];
             ^       ~~~~~~~~~
small.c:111:1: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
int321 (void)
^~~~~~
small.c:120:16: warning: comparison of distinct pointer types ('const short *'
and 'unsigned char *')
      && g_428 <= &g_429[1] ? : _fail ("", "rand005597.c",
         ~~~~~ ^  ~~~~~~~~~
small.c:120:33: warning: implicit declaration of function '_fail' is invalid in
C99 [-Wimplicit-function-declaration]
      && g_428 <= &g_429[1] ? : _fail ("", "rand005597.c",
                                ^
small.c:125:22: warning: implicit declaration of function 'safe' is invalid in
C99 [-Wimplicit-function-declaration]
  for (0; 1; l_366 = safe (l_366, 1))
                     ^
small.c:132:12: warning: incompatible pointer to integer conversion passing
'int (struct S6 ***const, signed char, unsigned int)' to parameter of type
'unsigned long long'
           func_78) >= (func_82 (g_114[1], g_252.f2.f0,
           ^~~~~~~
small.c:30:49: note: passing argument to parameter 'ui2' here
biz (unsigned long long ui1, unsigned long long ui2)
                                                ^
small.c:132:25: warning: implicit declaration of function 'func_82' is invalid
in C99 [-Wimplicit-function-declaration]
           func_78) >= (func_82 (g_114[1], g_252.f2.f0,
                        ^
small.c:137:15: warning: comparison of distinct pointer types ('short *' and
'unsigned char *')
      && g_94 <= &g_20[6] ? : __assert_fail ("", "rand005597.c", 757,
         ~~~~ ^  ~~~~~~~~
small.c:125:8: warning: expression result unused [-Wunused-value]
  for (0; 1; l_366 = safe (l_366, 1))
       ^
Assertion failed: (ConfluenceBlock->pred_size() == 2), function
VisitConditionalOperator, file /Volumes/Data/g/clang/lib/Analysis/CFG.cpp, line
1207.
0  clang             0x0000000100f81312 PrintStackTrace(void*) + 34
1  clang             0x0000000100f818b9 SignalHandler(int) + 857
2  libSystem.B.dylib 0x00007fff88fcb67a _sigtramp + 26
3  libSystem.B.dylib 0x0000000101917da0 _sigtramp + 2023016256
4  clang             0x000000010001cba6 abort + 22
5  clang             0x000000010001cb68 __assert_rtn + 56
6  clang             0x000000010050d467 (anonymous
namespace)::CFGBuilder::Visit(clang::Stmt*, (anonymous
namespace)::AddStmtChoice) + 18999
7  clang             0x000000010050d872 (anonymous
namespace)::CFGBuilder::VisitCompoundStmt(clang::CompoundStmt*) + 226
8  clang             0x000000010050c8ad (anonymous
namespace)::CFGBuilder::Visit(clang::Stmt*, (anonymous
namespace)::AddStmtChoice) + 15997
9  clang             0x000000010050ba63 (anonymous
namespace)::CFGBuilder::Visit(clang::Stmt*, (anonymous
namespace)::AddStmtChoice) + 12339
10 clang             0x000000010050b136 (anonymous
namespace)::CFGBuilder::Visit(clang::Stmt*, (anonymous
namespace)::AddStmtChoice) + 9990
11 clang             0x000000010050d872 (anonymous
namespace)::CFGBuilder::VisitCompoundStmt(clang::CompoundStmt*) + 226
12 clang             0x000000010050c8ad (anonymous
namespace)::CFGBuilder::Visit(clang::Stmt*, (anonymous
namespace)::AddStmtChoice) + 15997
13 clang             0x000000010050330c clang::CFG::buildCFG(clang::Decl
const*, clang::Stmt*, clang::ASTContext*, clang::CFG::BuildOptions) + 1676
14 clang             0x000000010050082a clang::AnalysisContext::getCFG() + 218
15 clang             0x00000001002710c6
clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy,
clang::Decl const*, clang::QualType) + 1542
16 clang             0x00000001002ee193
clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 2067
17 clang             0x000000010026640e
clang::Parser::ParseFunctionStatementBody(clang::Decl*) + 142
18 clang             0x000000010026eb24
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 548
19 clang             0x000000010023f452
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*) + 770
20 clang             0x000000010026e5f8
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AttributeList*, clang::AccessSpecifier) + 776
21 clang             0x000000010026e793
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*,
clang::AccessSpecifier) + 339
22 clang             0x000000010026deee
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList,
clang::Parser::ParsingDeclSpec*) + 2302
23 clang             0x000000010026d5dd
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 205
24 clang             0x000000010023a2e0 clang::ParseAST(clang::Sema&, bool) +
720
25 clang             0x0000000100206667 clang::CodeGenAction::ExecuteAction() +
823
26 clang             0x00000001000453d7
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 871
27 clang             0x0000000100024d25
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2757
28 clang             0x000000010001e39f cc1_main(char const**, char const**,
char const*, void*) + 5583
29 clang             0x00000001000216df main + 735
30 clang             0x000000010001cdc4 start + 52
Stack dump:
0.    Program arguments: /Volumes/Data/b/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -emit-obj -disable-free -main-file-name small.c
-pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 97.17 -resource-dir
/Volumes/Data/b/Release+Asserts/bin/../lib/clang/2.9 -O3 -ferror-limit 19
-fmessage-length 236 -stack-protector 1 -fblocks -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/7i/7ikIVQ+1FxmS1CawLKGczU+++TI/-Tmp-/cc-kFZsN1.o -x c small.c 
1.    small.c:144:1: current parser token 'int'
2.    small.c:112:1: parsing function body 'int321'
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Mon Nov 15 16:59:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 16:59:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8619] [clang cfg] Assertion failed:
 (ConfluenceBlock->pred_size() == 2), function VisitConditionalOperator,
 file /Volumes/Data/g/clang/lib/Analysis/CFG.cpp, line 1207.
In-Reply-To: <bug-8619-206@http.llvm.org/bugs/>
References: <bug-8619-206@http.llvm.org/bugs/>
Message-ID: <20101115225945.5DC7D2A6C12E@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2010-11-15 16:59:44 CST ---
Fixed:

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

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

From bugzilla-daemon at llvm.org  Mon Nov 15 18:09:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 18:09:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 8620] New: Assertion `false && "Ran out of
 registers during register allocation!"' failed.
Message-ID: <bug-8620-206@http.llvm.org/bugs/>

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

           Summary: Assertion `false && "Ran out of registers during
                    register allocation!"' 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


Filing this separately from PR8362, PR5010, PR4668 since those all involve
inline assembly, and this one doesn't.  Apologies if that wasn't right.

[regehr at n6 ~]$ clang -v

clang version 2.9 (trunk 119288)
Target: i386-pc-linux-gnu
Thread model: posix

[regehr at n6 ~]$ clang -c -w -Os small.c

clang: RegAllocLinearScan.cpp:1192:
void<unnamed>::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*):
Assertion `false && "Ran out of registers during register allocation!"' failed.
0  clang 0x09400018
Stack dump:
0.    Program arguments:
/mnt/local/randomtest/compiler-install/llvm-gcc-r119288-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.1 -resource-dir
/mnt/local/randomtest/compiler-install/llvm-gcc-r119288-install/bin/../lib/clang/2.9
-Os -w -ferror-limit 19 -fmessage-length 88 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'small.c'.
4.    Running pass 'Linear Scan Register Allocator' on function '@int641'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at n6 ~]$ cat small.c

static unsigned char
foo (signed char si1, unsigned char si2)
{
  return si1 + si2;
}

static unsigned char
bar (signed char left, int right)
{
  return left || right || right ? left : left >> right;
}

static long long
baz (long long si1, long long si2)
{
  return si2 || si1 && si2 ? si1 : (si1 % si2);
}

static unsigned char
bux (unsigned char ui1, unsigned char ui2)
{
  return ui1 + ui2;
}

static unsigned char
biz (unsigned short left, int right)
{
  return right < right >= left >> right ? : left << right;
}

volatile unsigned char g_5[4][4][4][1][1][1][1] = {
};

unsigned long long g_6;
unsigned char g_393[3][4] = {
};

int641 (void)
{
  unsigned char l_4[6][10];
  unsigned char l_20[10][4];
  unsigned char *l = &g_393[1][2];
  short l_399[3];
  int i, j;
  for (j = 0; j < 10; j++)
    l_4[i][j] = 0;
  l_399[i] = 0;
  *l |= baz (+l_4[5][6]
         && g_5[0][0][2][0][0][0][0] > 1,
         g_6) >
    foo (biz
     (bar (bux (g_6, l_4[5][6]), 0), (l_20[3][1], 0) || g_6), l_20[3][1]);
  *l =
    safe (l_399[2] & l_4[5][6]),
    l_399[2] > !l_20[5][1] <= l_399[2] >= l_399[1];
}

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

From bugzilla-daemon at llvm.org  Mon Nov 15 18:13:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 18:13:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 8608] unheralded conversion to bool
In-Reply-To: <bug-8608-206@http.llvm.org/bugs/>
References: <bug-8608-206@http.llvm.org/bugs/>
Message-ID: <20101116001317.60B0D2A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-11-15 18:13:16 CST ---
Fixed in r119293.

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

From bugzilla-daemon at llvm.org  Mon Nov 15 18:41:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 18:41:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8604] Assertion `(unsigned)FI-LowSpillSlot <
 SpillSlotToUsesMap.size() && "Invalid spill slot"' failed.
In-Reply-To: <bug-8604-206@http.llvm.org/bugs/>
References: <bug-8604-206@http.llvm.org/bugs/>
Message-ID: <20101116004146.CDE602A6C12D@llvm.org>

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

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

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

--- Comment #3 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-11-15 18:41:46 CST ---
Fixed in r119306, 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 Nov 15 19:01:37 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 19:01:37 -0600 (CST)
Subject: [LLVMbugs] [Bug 8621] New: error in backend: Unsupported asm: input
 constraint with a matching output constraint of incompatible type!
Message-ID: <bug-8621-206@http.llvm.org/bugs/>

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

           Summary: error in backend: Unsupported asm: input constraint
                    with a matching  output constraint of incompatible
                    type!
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: santosh.nagarakatte at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I am compiling bitvisor-1.1, a hypervisor using clang from the trunk with
revision 119293. I am using ubuntu-maverick 10.10 on x86-64.

When compiling the cpu_interpreter.c file. I am getting the following error.


fatal error: error in backend: Unsupported asm: input constraint with a
matching
      output constraint of incompatible type!

I have attached the .i file with this bug report and cc1 command line is given
below.

clang -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name
cpu_interpreter.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -disable-red-zone -target-cpu x86-64
-target-feature -sse -target-linker-version 2.20.51 -v -g -nostdinc
-resource-dir
/home/santoshn/llvm/llvm-svn-obj/Debug+Asserts/bin/../lib/clang/2.9 -O2 -Wall
-ferror-limit 19 -fmessage-length 80 -fno-builtin -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o cpu_interpreter.s -x
cpp-output cpu_interpreter.i

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

From bugzilla-daemon at llvm.org  Mon Nov 15 21:53:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 15 Nov 2010 21:53:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 8622] New: Assertion
	`currentLoop->isLCSSAForm(*DT)' failed.
Message-ID: <bug-8622-206@http.llvm.org/bugs/>

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

           Summary: Assertion `currentLoop->isLCSSAForm(*DT)' 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/tmp341$ clang -v

clang version 2.9 (trunk 119317)
Target: i386-pc-linux-gnu
Thread model: posix

regehr at home:~/volatile/bugs/tmp341$ clang -O3 -c -w small.c

clang: LoopUnswitch.cpp:215: virtual
bool<unnamed>::LoopUnswitch::runOnLoop(llvm::Loop*, llvm::LPPassManager&):
Assertion `currentLoop->isLCSSAForm(*DT)' failed.
0  clang 0x093d9048
Stack dump:
0.    Program arguments:
/mnt/z/z/compiler-install/llvm-gcc-r119317-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 -resource-dir
/mnt/z/z/compiler-install/llvm-gcc-r119317-install/bin/../lib/clang/2.9 -O3 -w
-ferror-limit 19 -fmessage-length 94 -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 'Loop Pass Manager' on function '@func_67'
5.    Running pass 'Unswitch loops' on basic block '%for.body'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

regehr at home:~/volatile/bugs/tmp341$ cat small.c

static int
safe_sub_func_int_s_s (int si1, int si2)
{
  return si1 ^ si2 & -si2 ^ si2 < 0 ? : si1 - si2;
}

struct S0
{
  const unsigned f0;
};
int g_38;
struct S0
func_67 (struct S0 p_68, unsigned p_69)
{
  for (0; g_38; g_38 = safe_sub_func_int_s_s (g_38, 1))
    {
      int *l_72 = &g_38;
      *l_72 = p_68.f0;
      for (0; p_69; p_69 += 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 Nov 16 00:50:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 00:50:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 8623] New: destructor not called on temporary in
	ternary
Message-ID: <bug-8623-206@http.llvm.org/bugs/>

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

           Summary: destructor not called on temporary in ternary
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


An object constructed in one side of a ?: expression doesn't get its
constructor called. Here's an example program demonstrating the problem:

  #include <cstdio>
  using namespace std;

  struct X {
    X() { printf("X() : %x\n", this); }
    ~X() { printf("~X() : %x\n", this); }
    X(const X &other) { printf("X(const X& %x) : %x\n", &other, this); }
  };

  struct Y {
    Y() { printf("Y() : %x\n", this); }
    ~Y() { printf("~Y() : %x\n", this); }
    Y(const Y &other) { printf("Y(const Y& %x) : %x\n", &other, this); }

    X ToString() const { return X(); }
  };

  int main(int argc, char** argv) {
    Y y;
    0 ? X() : y.ToString();
  }

which emits:

  $ clang++ -O0 -g ternary-leak.cc -o ternary-leak -Wno-format
  $ ./ternary-leak 
  Y() : 96ceb008
  X() : 96ceb000
  ~Y() : 96ceb008

I don't think that's permitted. By contrast, g++ shows two calls to ~X() and
indeed if I just replace the line in main with "y.ToString();" then ~X() is
called.

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

From bugzilla-daemon at llvm.org  Tue Nov 16 02:10:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 02:10:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 8624] New: Possible llvm problem when ModulePass
 requires FunctionPasses
Message-ID: <bug-8624-206@http.llvm.org/bugs/>

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

           Summary: Possible llvm problem when ModulePass requires
                    FunctionPasses
           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: zhousheng00 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5786)
 --> (http://llvm.org/bugs/attachment.cgi?id=5786)
Experimental Pass

Consider a case when a module pass requires two function passes fp1, fp2. When
getAnalysis<fp1>() is called, both fp1 and fp2 are executed. That is fine. In
the worst case, we just spend lots of time running the analysis passes many
times.

But it should not crash. In the experimental pass, command "opt" got an
assertion.

The experimental pass is attached. Using the following command:

$ opt -load LLVMTestPass.so  -mpass x.bc -o y.bc

got:

MyFPass running on __cxx_global_var_init
MyFPass2 running on __cxx_global_var_init
opt:
/developer/home2/zsth/projects/llvm.org/llvm/include/llvm/PassAnalysisSupport.h:239:
AnalysisType& llvm::Pass::getAnalysisID(const void*, llvm::Function&) [with
AnalysisType = MyFPass]: Assertion `ResultPass && "Unable to find requested
analysis info"' failed.


Seems the function pass fp1 and fp2 were correctly invoked by the module pass,
but why it dumped the assertion at last.

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

From bugzilla-daemon at llvm.org  Tue Nov 16 02:17:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 02:17:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 8625] New: Incorrect warning with -Wformat=2
Message-ID: <bug-8625-206@http.llvm.org/bugs/>

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

           Summary: Incorrect warning with -Wformat=2
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: csaba_22 at yahoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code:

enum error_type_t {
 none, warn, err, fatal
};

void error(error_type_t p_et, const char *fmt, ...)
   __attribute__ ((__format__ (__printf__, 2, 3)))
    ;

class ErrorContext {
public:

 ErrorContext();

 ErrorContext(const char *fmt, ...)
   __attribute__ ((__format__ (__printf__, 2, 3))); // 'this' is at 1

 ~ErrorContext();

 static void error(error_type_t p_et, const char *fmt, ...)
   __attribute__ ((__format__ (__printf__, 2, 3)))
     ;

 static void error_internal(const char *fmt, ...)
   __attribute__ ((__format__ (__printf__, 1, 2), __noreturn__));
};

int main(int argc, char **argv)
{
 if (argc < 2 ) {
   ErrorContext ec("While checking arguments");
   if (argc < 1) {
     ec.error_internal("argc=%d is not possible", argc);
   }
   ec.error(fatal, "Not enough arguments for %s", argv[0]); // line 34
   error   (fatal, "Not enough arguments for %s", argv[0]);
 }
 return 0;
}

and the following commandline

clang++ -c -Wformat=2 example.cc

generates a spurious warning:

example.cc:34:14: warning: format string is not a string literal
[-Wformat-nonliteral]
   ec.error(fatal, "Not enough arguments for %s", argv[0]);
            ^~~~~

The handling of the static method "error" seems to be inconsistent
with the free function "error" (there is no warning for line 35).

$ clang++ --version
clang version 2.9 (trunk 119134)
Target: x86_64-unknown-linux-gnu
Thread model: posix

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

From bugzilla-daemon at llvm.org  Tue Nov 16 02:53:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 02:53:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 8625] Incorrect warning with -Wformat=2
In-Reply-To: <bug-8625-206@http.llvm.org/bugs/>
References: <bug-8625-206@http.llvm.org/bugs/>
Message-ID: <20101116085354.977AA2A6C12C@llvm.org>

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

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> 2010-11-16 02:53:54 CST ---
Should be fixed in r119340. File more bugs if you find any other places where
we make this mistake with argument indices in attributes and static member
function calls.

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

From bugzilla-daemon at llvm.org  Tue Nov 16 10:19:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 10:19:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 8626] New: clang++ produces poor diagnostic for
 function-style cast with no matching constructors
Message-ID: <bug-8626-206@http.llvm.org/bugs/>

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

           Summary: clang++ produces poor diagnostic for function-style
                    cast with no matching constructors
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Given this code:

struct A {};
struct B {};
struct C { C(A, B); };
C f(B &b) { return C(A()); }


clang++ says the following:

clang-fsc.cpp:4:20: error: functional-style cast from 'A' to 'C' is not allowed
C f(B &b) { return C(A()); }
                   ^
1 error generated.


g++ produces a much more helpful diagnostic:

clang-fsc.cpp: In function ?C f(B&)?:
clang-fsc.cpp:4: error: no matching function for call to ?C::C(A)?
clang-fsc.cpp:3: note: candidates are: C::C(A, B)
clang-fsc.cpp:3: note:                 C::C(const 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 Nov 16 11:55:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 11:55:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8333] 0 size allocations
In-Reply-To: <bug-8333-206@http.llvm.org/bugs/>
References: <bug-8333-206@http.llvm.org/bugs/>
Message-ID: <20101116175536.39C302A6C12C@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2010-11-16 11:55:36 CST ---


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

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

From bugzilla-daemon at llvm.org  Tue Nov 16 13:55:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 13:55:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 8620] Assertion `false && "Ran out of registers
 during register allocation!"' failed.
In-Reply-To: <bug-8620-206@http.llvm.org/bugs/>
References: <bug-8620-206@http.llvm.org/bugs/>
Message-ID: <20101116195538.C95852A6C124@llvm.org>

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

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

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

--- Comment #5 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2010-11-16 13:55:38 CST ---
Fixed in r119375, thanks!

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

From bugzilla-daemon at llvm.org  Tue Nov 16 15:52:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 15:52:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 8627] New: CMake breaks in x86_64-pc-win32
Message-ID: <bug-8627-206@http.llvm.org/bugs/>

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

           Summary: CMake breaks in x86_64-pc-win32
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: louis.zhuang at acm.org
                CC: llvmbugs at cs.uiuc.edu


CMake failed in Visual Studio 10 Win64 build. Following patch would fix the
issue.

Index: lib/Target/X86/CMakeLists.txt
===================================================================
--- lib/Target/X86/CMakeLists.txt    (revision 119001)
+++ lib/Target/X86/CMakeLists.txt    (working copy)
@@ -42,10 +42,10 @@
   enable_language(ASM_MASM)
   ADD_CUSTOM_COMMAND(
     OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/X86CompilationCallback_Win64.obj
+    MAIN_DEPENDENCY X86CompilationCallback_Win64.asm
     COMMAND ${CMAKE_ASM_MASM_COMPILER} /Fo
${CMAKE_CURRENT_BINARY_DIR}/X86CompilationCallback_Win64.obj /c
${CMAKE_CURRENT_SOURCE_DIR}/X86CompilationCallback_Win64.asm
-    DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/X86CompilationCallback_Win64.asm
    )
-   set(sources ${sources}
${CMAKE_CURRENT_BINARY_DIR}/X86CompilationCallback_Win64.obj)
+   set(sources ${sources} X86CompilationCallback_Win64.asm)
 endif()

 add_llvm_target(X86CodeGen ${sources})

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

From bugzilla-daemon at llvm.org  Tue Nov 16 16:04:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 16:04:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 8628] New: PTX CodeGen depends on MC,
 doesn't build with clang -O0
Message-ID: <bug-8628-206@http.llvm.org/bugs/>

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

           Summary: PTX CodeGen depends on MC, doesn't build with clang
                    -O0
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PTX
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


Function PTXMCAsmStreamer::EmitDwarfFileDirective in
lib/Target/PTX/PTXMCAsmStreamer.cpp contains a call to
MCStreamer::EmitDwarfFileDirective.

When built with clang -O0, tools which do link against the CodeGen libraries
but don't link against the MC library fail to build:

Undefined symbols:
  "llvm::MCStreamer::EmitDwarfFileDirective(unsigned int, llvm::StringRef)",
referenced from:
      llvm::PTXMCAsmStreamer::EmitDwarfFileDirective(unsigned int,
llvm::StringRef) in libLLVMPTXCodeGen.a(PTXMCAsmStreamer.o)
  "llvm::MCStreamer::EmitDwarfLocDirective(unsigned int, unsigned int, unsigned
int, unsigned int, unsigned int, unsigned int)", referenced from:
      vtable for llvm::PTXMCAsmStreamer in
libLLVMPTXCodeGen.a(PTXMCAsmStreamer.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 Nov 16 16:11:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 16:11:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 8627] CMake breaks in x86_64-pc-win32
In-Reply-To: <bug-8627-206@http.llvm.org/bugs/>
References: <bug-8627-206@http.llvm.org/bugs/>
Message-ID: <20101116221109.1C1842A6C12D@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ofv at wanadoo.es
         Resolution|                            |FIXED

--- Comment #1 from ?scar Fuentes <ofv at wanadoo.es> 2010-11-16 16:11:08 CST ---
Patch applied in r119394.

Next time please provide patches as attachments, for avoiding line wrapping.
Thanks!

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

From bugzilla-daemon at llvm.org  Tue Nov 16 16:34:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 16:34:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 8628] PTX CodeGen depends on MC,
	doesn't build with clang -O0
In-Reply-To: <bug-8628-206@http.llvm.org/bugs/>
References: <bug-8628-206@http.llvm.org/bugs/>
Message-ID: <20101116223411.6AFED2A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #1 from Dan Gohman <gohman at apple.com> 2010-11-16 16:34:11 CST ---
Never mind, this appears to be a quirk of my build setup.

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

From bugzilla-daemon at llvm.org  Tue Nov 16 18:07:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 18:07:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 8623] destructor not called on temporary in ternary
In-Reply-To: <bug-8623-206@http.llvm.org/bugs/>
References: <bug-8623-206@http.llvm.org/bugs/>
Message-ID: <20101117000747.D976A2A6C124@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-11-16 18:07:47 CST ---
Fixed in r119408.

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

From bugzilla-daemon at llvm.org  Tue Nov 16 22:51:10 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 22:51:10 -0600 (CST)
Subject: [LLVMbugs] [Bug 8629] New: clang++ fails an assertion
Message-ID: <bug-8629-206@http.llvm.org/bugs/>

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

           Summary: clang++ fails an assertion
           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


pipping at bogus ~/delta $ clang++ -S dgfparserblocks.ii -w
clang:
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/lib/Sema/../../include/clang/AST/DeclTemplate.h:1253:
void
clang::ClassTemplateSpecializationDecl::setPointOfInstantiation(clang::SourceLocation):
Assertion `Loc.isValid() && "point of instantiation must be valid!"' failed.
0  libLLVM-2.9svn.so 0x00007fc803884a0f
1  libLLVM-2.9svn.so 0x00007fc803884ff9
2  libpthread.so.0   0x00007fc802d13fa0
3  libc.so.6         0x00007fc80202b165 gsignal + 53
4  libc.so.6         0x00007fc80202c3ff abort + 383
5  libc.so.6         0x00007fc802024351 __assert_fail + 241
6  clang             0x00000000008fad6d
clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*,
clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&,
clang::TemplateSpecializationKind, bool) + 2061
7  clang             0x00000000008fb499
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 1769
8  clang             0x000000000091e317
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&, std::pair<clang::SourceLocation,
clang::PartialDiagnostic>) + 327
9  clang             0x000000000091e71d
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&) + 77
10 clang             0x0000000000772725
clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&,
clang::DeclContext*) + 341
11 clang             0x00000000008b674e
clang::Sema::LookupTemplateName(clang::LookupResult&, clang::Scope*,
clang::CXXScopeSpec&, clang::QualType, bool, bool&) + 254
12 clang             0x00000000008b64a0
clang::Sema::isTemplateName(clang::Scope*, clang::CXXScopeSpec&, bool,
clang::UnqualifiedId&, clang::OpaquePtr<clang::QualType>, bool,
clang::OpaquePtr<clang::TemplateName>&, bool&) + 368
13 clang             0x00000000008beb89
clang::Sema::ActOnDependentTemplateName(clang::Scope*, clang::SourceLocation,
clang::CXXScopeSpec&, clang::UnqualifiedId&, clang::OpaquePtr<clang::QualType>,
bool, clang::OpaquePtr<clang::TemplateName>&) + 505
14 clang             0x0000000000908fe3
15 clang             0x00000000009095f2
16 clang             0x000000000090a752
17 clang             0x000000000090a3fb
18 clang             0x0000000000908850
19 clang             0x00000000008fee27
20 clang             0x000000000090bbd5
21 clang             0x0000000000900dc3
22 clang             0x00000000008fd3ca
23 clang             0x000000000090b27d
24 clang             0x00000000008fc2ea
25 clang             0x00000000008fbaac clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 60
26 clang             0x000000000091511c
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 1772
27 clang             0x00000000009159d8
clang::Sema::PerformPendingInstantiations(bool) + 296
28 clang             0x0000000000915203
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2003
29 clang             0x00000000009159d8
clang::Sema::PerformPendingInstantiations(bool) + 296
30 clang             0x0000000000915203
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2003
31 clang             0x00000000009159d8
clang::Sema::PerformPendingInstantiations(bool) + 296
32 clang             0x0000000000915203
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2003
33 clang             0x00000000009159d8
clang::Sema::PerformPendingInstantiations(bool) + 296
34 clang             0x0000000000915203
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2003
35 clang             0x00000000009159d8
clang::Sema::PerformPendingInstantiations(bool) + 296
36 clang             0x0000000000915203
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2003
37 clang             0x00000000009159d8
clang::Sema::PerformPendingInstantiations(bool) + 296
38 clang             0x000000000076367a
clang::Sema::ActOnEndOfTranslationUnit() + 42
39 clang             0x0000000000731f66
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 38
40 clang             0x0000000000722ade clang::ParseAST(clang::Sema&, bool) +
702
41 clang             0x00000000006125b5 clang::CodeGenAction::ExecuteAction() +
709
42 clang             0x0000000000532927
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 903
43 clang             0x0000000000516dcf
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2767
44 clang             0x000000000050ffbb cc1_main(char const**, char const**,
char const*, void*) + 5899
45 clang             0x00000000005139ff main + 655
46 libc.so.6         0x00007fc802017ced __libc_start_main + 253
47 clang             0x000000000050e7e9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S
-disable-free -main-file-name dgfparserblocks.ii -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.20.1.20100303 -resource-dir
/usr/bin/../lib/clang/2.9 -w -ferror-limit 19 -fmessage-length 118 -fexceptions
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
dgfparserblocks.s -x c++-cpp-output dgfparserblocks.ii 
1.      <eof> parser at end of file
2.      dgfparserblocks.ii:138:75: instantiating function definition
'generateCubeFace'
3.      dgfparserblocks.ii:133:55: instantiating function definition 'cube'
4.      dgfparserblocks.ii:121:50: instantiating function definition 'instance'
5.      dgfparserblocks.ii:125:22: instantiating function definition
'GenericReferenceElementContainer'
6.      dgfparserblocks.ii:104:62: instantiating function definition
'initialize'
7.      dgfparserblocks.ii:99:45: instantiating function definition
'initializeTopology'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)
pipping at bogus ~/delta $

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

From bugzilla-daemon at llvm.org  Tue Nov 16 23:17:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 23:17:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 8630] New: Don't complain about '-g' in link
	commands
Message-ID: <bug-8630-206@http.llvm.org/bugs/>

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

           Summary: Don't complain about '-g' in link commands
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ clang --version
clang version 2.9 (trunk 119002)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ echo "int main() { return 0; }" | clang -xc - -c -o main.o
$ clang -g main.o
clang: warning: argument unused during compilation: '-g'

The warning is a lie (no compilation is happening).
It is also annoying.

It also causes many GDB testsuite "unresolved" outcomes, because
TCL/runtest/expect thinks that if a command produced stderr output,
then the command failed:

$ expect
expect1.1> exec clang -g main.o
clang: warning: argument unused during compilation: '-g'
   while executing                      <<< this indicates TCL exception
"exec clang -g main.o"
expect1.2> exec /bin/true
expect1.3> exec /bin/false
child process exited abnormally
   while executing
"exec /bin/false"
expect1.4>

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

From bugzilla-daemon at llvm.org  Tue Nov 16 23:30:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 23:30:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 8631] New: Clang integrated-as doesn't support
 .2byte .4byte .8byte ASM directives
Message-ID: <bug-8631-206@http.llvm.org/bugs/>

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

           Summary: Clang integrated-as doesn't support .2byte .4byte
                    .8byte ASM directives
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: rafael.espindola at gmail.com, llvmbugs at cs.uiuc.edu


gdb/testsuite/gdb.arch/amd64-disp-step.S contains:

/* test rip-relative data */
answer: .8byte 42

clang chokes on that:

 clang ../../../src/gdb/testsuite/gdb.arch/amd64-disp-step.S -g -lm -o
amd64-disp-step
/tmp/cc-oCEzi4.s:129:9: warning: ignoring directive for now
answer: .8byte 42

>From binutils/src/gas/doc/c-arm.texi

@cindex @code{.2byte} directive, ARM
@cindex @code{.4byte} directive, ARM
@cindex @code{.8byte} directive, ARM
@item .2byte @var{expression} [, @var{expression}]*
@itemx .4byte @var{expression} [, @var{expression}]*
@itemx .8byte @var{expression} [, @var{expression}]*
These directives write 2, 4 or 8 byte values to the output section.

Even though the doc would lead you to believe that this is ARM-specific,
GNU-as accepts this for x86

Also, gdb/testsuite/gdb.dwarf2/dup-psym.S has:
 .int 0

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

From bugzilla-daemon at llvm.org  Tue Nov 16 23:32:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 23:32:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 8632] New: Clang integrated-as doesn't support
 .cfi_startproc, .cfi_signal_frame, etc. ASM directives
Message-ID: <bug-8632-206@http.llvm.org/bugs/>

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

           Summary: Clang integrated-as doesn't support .cfi_startproc,
                    .cfi_signal_frame, etc. ASM directives
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: rafael.espindola at gmail.com, llvmbugs at cs.uiuc.edu


With .cfi directives writing assembly with proper unwind descriptors is so much
easier.
Unfortunately, clang doesn't support any of that:

warning: ignoring directive for now
  .cfi_startproc

http://sourceware.org/binutils/docs/as/CFI-directives.html

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

From bugzilla-daemon at llvm.org  Tue Nov 16 23:39:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 23:39:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 8633] New: Clang integrated-as doesn't support
 .pushsection .popsection ASM directives
Message-ID: <bug-8633-206@http.llvm.org/bugs/>

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

           Summary: Clang integrated-as doesn't support .pushsection
                    .popsection ASM directives
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: rafael.espindola at gmail.com, llvmbugs at cs.uiuc.edu


gdb/testsuite/gdb.python/py-section-script.c has:

#define DEFINE_GDB_SCRIPT(script_name) \
 asm("\
.pushsection \".debug_gdb_scripts\", \"MS\", at progbits,1\n\
.byte 1\n\
.asciz \"" script_name "\"\n\
.popsection \n\
");

DEFINE_GDB_SCRIPT ("py-section-script.py")

clang doesn't like any of that:

clang -c ../../src/gdb/testsuite/gdb.python/py-section-script.c
<inline asm>:1:1: error: warning: ignoring directive for now
.pushsection ".debug_gdb_scripts", "MS", at progbits,1
^
<inline asm>:4:1: error: warning: ignoring directive for now
.popsection
^
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  Tue Nov 16 23:41:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 16 Nov 2010 23:41:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 8613] Copy constructor of SwitchInst does not call
 SwitchInst::init
In-Reply-To: <bug-8613-206@http.llvm.org/bugs/>
References: <bug-8613-206@http.llvm.org/bugs/>
Message-ID: <20101117054156.3D2B82A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-16 23:41:55 CST ---
nice catch, fixed in r119463

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

From bugzilla-daemon at llvm.org  Wed Nov 17 03:31:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 03:31:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 8113] MachineMemOperands not propageted in
 ARMLoadStoreOptimizer.cpp
In-Reply-To: <bug-8113-206@http.llvm.org/bugs/>
References: <bug-8113-206@http.llvm.org/bugs/>
Message-ID: <20101117093134.1F8422A6C124@llvm.org>

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

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

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

--- Comment #3 from Evan Cheng <evan.cheng at apple.com> 2010-11-17 03:31:33 CST ---
And reverted because it broke 176.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  Wed Nov 17 04:37:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 04:37:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 8634] New: Cleanup tablegen
Message-ID: <bug-8634-206@http.llvm.org/bugs/>

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

           Summary: Cleanup tablegen
           Product: Build scripts
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: louis.zhuang at acm.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5791)
 --> (http://llvm.org/bugs/attachment.cgi?id=5791)
cleanup tablegen

tablegen should not generate redundant *.tmp.rule

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

From bugzilla-daemon at llvm.org  Wed Nov 17 05:31:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 05:31:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 8635] New: may_alias attribute on function
 parameter gives warning
Message-ID: <bug-8635-206@http.llvm.org/bugs/>

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

           Summary: may_alias attribute on function parameter gives
                    warning
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu


Compiling the following file with Clang built from trunk gives the following
warning:

void f(int __attribute__((may_alias)) *x) {
}

/tmp/a.cc:1:27: warning: 'may_alias' attribute only applies to variable and
function types
void f(int __attribute__((may_alias)) *x) {
                          ^
1 warning generated.


It seems this was introduced in
http://llvm.org/viewvc/llvm-project?view=rev&revision=119407

I'm not familiar with this stuff, but it seems may_alias can be used both as a
type and a variable attribute and Clang only recognizes the former?


(This breaks the Chromium/Clang build because glib headers use this attribute
all over the place and the warnings gets treated as an error.)

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

From bugzilla-daemon at llvm.org  Wed Nov 17 08:09:13 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 08:09:13 -0600 (CST)
Subject: [LLVMbugs] [Bug 8636] New: clang chews through stack space
Message-ID: <bug-8636-206@http.llvm.org/bugs/>

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

           Summary: clang chews through stack space
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu


Been tracking down a memory exhaustion problem in automatically generated code
with clang which does not occur with gcc.

The following code shows our problem:

#include <stdio.h>

#define X1(x) if(i) { x } else { x }
#define X2(x) if(i) { x } else { x }
#define X3(x) if(i) { x } else { x }
#define X4(x) if(i) { x } else { x }
#define X5(x) if(i) { x } else { x }
#define X6(x) if(i) { x } else { x }
#define X7(x) if(i) { x } else { x }
#define X8(x) if(i) { x } else { x }
#define ARRAY { int x[4000]; printf("%ld\n", (y - x)); }
  void f(int i)
  {
int y[1];
X1(X2(X3(X4(X5(X6(X7(X8(ARRAY))))))));

  }

  int main(int argc, char** argv) {
    f(0);
  }

With no optimisation, gcc outputs 4000 while clang outputs 1024002. if I
increase the depth 2 more steps (the actual size we use in practice), a
clang-compiled executable just segfaults, while the gcc one works happily.

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

From bugzilla-daemon at llvm.org  Wed Nov 17 09:08:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 09:08:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 8630] Don't complain about '-g' in link commands
In-Reply-To: <bug-8630-206@http.llvm.org/bugs/>
References: <bug-8630-206@http.llvm.org/bugs/>
Message-ID: <20101117150809.B7AFC2A6C12F@llvm.org>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rafael.espindola at gmail.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-17 09:08:09 CST ---


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

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

From bugzilla-daemon at llvm.org  Wed Nov 17 09:17:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 09:17:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 8607] "argument unused during compilation" warning
	unclear
In-Reply-To: <bug-8607-206@http.llvm.org/bugs/>
References: <bug-8607-206@http.llvm.org/bugs/>
Message-ID: <20101117151753.ECB2E2A6C12E@llvm.org>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-17 09:17:53 CST ---
Fixed in 119498.

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

From bugzilla-daemon at llvm.org  Wed Nov 17 09:34:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 09:34:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 8637] New: ARM backend produces AAPCS-incompatible
	code
Message-ID: <bug-8637-206@http.llvm.org/bugs/>

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

           Summary: ARM backend produces AAPCS-incompatible code
           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: yarogami at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

Compiling the following C program for arm produces a binary that prints "0.0":

//test.c
#include <stdio.h>
int main() {
  printf("%f\n", 4.6);
  return 0;
}

x86_64$ clang -S -emit-llvm -o test.ll test.c
x86_64$ llc -march=arm -mcpu=cortex-a8 -O0 -o test.s test.ll
x86_64$ arm-linux-gnueabi-gcc-cvs -mcpu=cortex-a8 -mfpu=neon -o test test.s

arm$ ./test
0.000000

x86_64-scratchbox2$ sb2 ./test
0.000000


Clang and LLVM are fresh (r119494), but this happens also in the 2.8 release.
I'm using a cross-compiling gcc 4.6.0 (cvs) for assembling and linking.

Manually changing the "vmov    r1, r2, d16" to "vmov    r2, r3, d16" yields a
working arm-binary (see attached .s file). This is the instruction that brings
the double argument of printf into the argument registers. The AAPCS states
that double precision floats are 8-byte aligned, and should be passed in a
register pair starting with an even register (AAPCS 5.5 Parameter Passing: "A
double-word aligned type will always start in an even-numbered core register,
or at a double-word aligned address on the stack even if it is not the first
member of an aggregate."). It seems that llc disregards this.

The same thing happens with -O1, -O2 and -O3 (for llc). However, if I manually
add alignstack(4) to main() in the .ll file (while not manually tinkering with
the .s file), things go well for some reason. Or if I manually change the "sub
sp, sp, #12" to "sub sp, sp, #16", and leave the double argument in {r1,r2}. 
So maybe this is some stack alignment problem?

Perhaps this is related to bug 8040?

More info:

x86_64$ arm-linux-gnueabi-gcc-cvs -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc-cvs
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arm-linux-gnueabi/4.6.0/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../configure --prefix=/usr/local
--program-prefix=arm-linux-gnueabi- --program-suffix=-cvs
--target=arm-linux-gnueabi --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101110 (experimental) (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  Wed Nov 17 09:35:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 09:35:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 8638] New: crash during static analysis of
	objective.c file
Message-ID: <bug-8638-206@http.llvm.org/bugs/>

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

           Summary: crash during static analysis of objective.c file
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: multix79 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


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

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

From bugzilla-daemon at llvm.org  Wed Nov 17 09:37:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 09:37:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8639] New: Should be more conservative while
 issuing an unused argument warning
Message-ID: <bug-8639-206@http.llvm.org/bugs/>

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

           Summary: Should be more conservative while issuing an unused
                    argument warning
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu


The simplest testcase coming from MPlayer build system:

[~]> clang -march=core2 -march=core2 -c test.c 
clang: warning: argument unused during compilation: '-march=core2'

There is no need to warn about unused argument here since the arguments are
duplicates. espindola fixed a similar case with optimization flags in r119498
but we need a more generic way of handling 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  Wed Nov 17 10:17:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 10:17:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 8631] [MC] Clang integrated-as doesn't support
 .2byte .4byte .8byte ASM directives
In-Reply-To: <bug-8631-206@http.llvm.org/bugs/>
References: <bug-8631-206@http.llvm.org/bugs/>
Message-ID: <20101117161718.F0D7E2A6C124@llvm.org>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-17 10:17:18 CST ---
Fixed in r119511.

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

From bugzilla-daemon at llvm.org  Wed Nov 17 11:27:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 11:27:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 8635] may_alias attribute on function parameter
	gives warning
In-Reply-To: <bug-8635-206@http.llvm.org/bugs/>
References: <bug-8635-206@http.llvm.org/bugs/>
Message-ID: <20101117172715.346502A6C124@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #1 from Dan Gohman <gohman at apple.com> 2010-11-17 11:27:14 CST ---
I removed the warning in r119517.

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

From bugzilla-daemon at llvm.org  Wed Nov 17 17:02:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 17:02:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 8636] clang chews through stack space
In-Reply-To: <bug-8636-206@http.llvm.org/bugs/>
References: <bug-8636-206@http.llvm.org/bugs/>
Message-ID: <20101117230200.C55232A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-11-17 17:02:00 CST ---
yep, it would be great to fix this.

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

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

From bugzilla-daemon at llvm.org  Wed Nov 17 17:03:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 17:03:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 8634] Cleanup tablegen
In-Reply-To: <bug-8634-206@http.llvm.org/bugs/>
References: <bug-8634-206@http.llvm.org/bugs/>
Message-ID: <20101117230358.240F12A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-17 17:03:57 CST ---
Hi Louis,

The best way to get this patch reviewed is to send it to llvm-commits with a
[cmake] tag on the subject line.  That will get the attention of the
appropriate reviewers.  Thanks!

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

From bugzilla-daemon at llvm.org  Wed Nov 17 19:29:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 19:29:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 8640] New: template diagnostic does not show point
	of error
Message-ID: <bug-8640-206@http.llvm.org/bugs/>

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

           Summary: template diagnostic does not show point of error
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Clang should go to the root of template instantiations when virtual functions
are instantiated on 'new'. Here's the testcase:

  template<class T1> struct C1 {
    virtual void c1() {
      T1 t1 = 3;
    }
  };

  template<class T2> struct C2 {
    void c2() {
      new C1<T2>();
    }
  };

  void f() {
    C2<int*> c2;
    c2.c2();      // error here
  }

which produces the following errors:

$ clang++ -fsyntax-only b3205969.cc 
b3205969.cc:3:7: error: cannot initialize a variable of type 'int *' with an
      rvalue of type 'int'
   T1 t1 = 3;
      ^    ~
b3205969.cc:9:8: note: in instantiation of member function 'C1<int *>::c1'
      requested here
   new C1<T2>();
       ^
1 error generated.

Note how we don't actually trace all the way through to the site of the problem
in f(). If you instead changed c1() to be non-virtual then add a call to c1 in
c2() then you would get a note on the line marked "error here" as we expect.

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

From bugzilla-daemon at llvm.org  Wed Nov 17 19:30:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 19:30:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 7338] [clang arm] '+' constraint in inline assembly
In-Reply-To: <bug-7338-206@http.llvm.org/bugs/>
References: <bug-7338-206@http.llvm.org/bugs/>
Message-ID: <20101118013057.7B3422A6C12D@llvm.org>

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

John Thompson <John.Thompson.JTSoftware at gmail.com> changed:

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

--- Comment #7 from John Thompson <John.Thompson.JTSoftware at gmail.com> 2010-11-17 19:30:56 CST ---
Mult-alt constraint support framework implemented.  Some platform support still
needed.

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

From bugzilla-daemon at llvm.org  Wed Nov 17 19:37:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 19:37:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 8366] -march=native on i5 emits unaligned movaps
In-Reply-To: <bug-8366-206@http.llvm.org/bugs/>
References: <bug-8366-206@http.llvm.org/bugs/>
Message-ID: <20101118013739.5BC672A6C12D@llvm.org>

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

Dale Johannesen <dalej at apple.com> changed:

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

--- Comment #4 from Dale Johannesen <dalej at apple.com> 2010-11-17 19:37:38 CST ---
Fixed in 119605.

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

From bugzilla-daemon at llvm.org  Wed Nov 17 20:37:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 20:37:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 8641] New: Clang incorrectly warns of undefined
 behavior with printf specifier %#X
Message-ID: <bug-8641-206@http.llvm.org/bugs/>

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

           Summary: Clang incorrectly warns of undefined behavior with
                    printf specifier %#X
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: kevin at sb.org
                CC: llvmbugs at cs.uiuc.edu


Attempting to compile the following line of code:

    printf("%#X\n", 50);

results in a spurious warning:

foo.c:4:14: warning: flag '#' results in undefined behavior with 'X' conversion
      specifier [-Wformat]
    printf("%#X\n", 50);
            ~^~

This is incorrect. The '#' flag applies to 'X' just as well as it does to '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  Wed Nov 17 22:57:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 22:57:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8642] New: possible spurious divide by zero
Message-ID: <bug-8642-206@http.llvm.org/bugs/>

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

           Summary: possible spurious divide by zero
           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


Not sure what is going on here but the FPE looks fishy.

[regehr at n1 ~]$ clang -v
clang version 2.9 (trunk 119679)
Target: i386-pc-linux-gnu
Thread model: posix
[regehr at n1 ~]$ clang -O1 foo.c -o foo
[regehr at n1 ~]$ ./foo
[regehr at n1 ~]$ clang -O2 foo.c -o foo
[regehr at n1 ~]$ ./foo
Floating point exception
[regehr at n1 ~]$ cat foo.c
struct S1 {
   signed f0 : 19;
};

struct S1 g_2[2] = {{1}, {2}};
struct S1 g_4 = {3};
short g_19 = 0;

static short
foo(short si1, short si2)
{
  return (si2 == 0) ?  (si1) : (si1 % si2);
}

int main(int argc, char* argv[])
{
    struct S1 *l_48 = &g_2[1];
    struct S1 *l_49 = &g_4;
    g_19 = foo(1, (l_48 == l_49));
    return 0;
}

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

From bugzilla-daemon at llvm.org  Wed Nov 17 23:28:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 17 Nov 2010 23:28:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 8585] clang wrong at -O0?
In-Reply-To: <bug-8585-206@http.llvm.org/bugs/>
References: <bug-8585-206@http.llvm.org/bugs/>
Message-ID: <20101118052826.549A72A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #7 from Chris Lattner <clattner at apple.com> 2010-11-17 23:28:25 CST ---
Likely fixed, a couple -O0 bugs got tracked down recently.  woot.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 01:45:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 01:45:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 8643] New: [memcpyopt] missed memcpy optimization
Message-ID: <bug-8643-206@http.llvm.org/bugs/>

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

           Summary: [memcpyopt] missed memcpy optimization
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


Transforms/MemCpyOpt/memcpy.ll:@test1 optimizes into this, the memcpy can be
removed:


define void @ccosl(%0* sret %agg.result, x86_fp80 %z.0, x86_fp80 %z.1) nounwind
{
entry:
  %tmp2 = alloca %0
  %tmp5 = fsub x86_fp80 0xK80000000000000000000, %z.1
  call void @ccoshl(%0* sret %tmp2, x86_fp80 %tmp5, x86_fp80 %z.0) nounwind
  %tmp219 = bitcast %0* %tmp2 to i8*
  %agg.result21 = bitcast %0* %agg.result to i8*
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* %agg.result21, i8* %tmp219, i32 32,
i32 16, i1 false)
  ret void
}

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

From bugzilla-daemon at llvm.org  Thu Nov 18 02:12:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 02:12:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 8644] New: [memcpyopt] not optimizing away memcpy
	feeding byval
Message-ID: <bug-8644-206@http.llvm.org/bugs/>

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

           Summary: [memcpyopt] not optimizing away memcpy feeding byval
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


The testcase in PR8582 has a memcpy that isn't being eliminated, here's a
reduces testcase that memcpyopt + dse should eliminate:

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-apple-darwin10.0.0"


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

%T = type { i8, [123 x i8] }

define void @test3(i8 *%P) {
  %A = alloca %T
  %a = bitcast %T* %A to i8*
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %a, i8* %P, i64 124, i32 4, i1
false)
  call void @baz(i8* byval %a) 
  ret void
}

declare void @baz(i8* byval)

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

From bugzilla-daemon at llvm.org  Thu Nov 18 02:34:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 02:34:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 8645] New: Incorrect UTF-8 BOM while detecting
 unsupported encoding file
Message-ID: <bug-8645-206@http.llvm.org/bugs/>

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

           Summary: Incorrect UTF-8 BOM while detecting unsupported
                    encoding file
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: yuhuntero at gmail.com
                CC: llvmbugs at cs.uiuc.edu


llvm-2.8\tools\clang\lib\Basic\SourceManager.cpp

@Line 131

//------------------------------------------------------
    if (!isBufferInvalid()) {
      llvm::StringRef BufStr = Buffer.getPointer()->getBuffer();
      const char *BOM = 0;
      if (BufStr.startswith("\xFE\xBB\xBF"))
                              ^^^

        BOM = "UTF-8";
      else if (BufStr.startswith("\xFE\xFF"))
        BOM = "UTF-16 (BE)";
      else if (BufStr.startswith("\xFF\xFE"))
        BOM = "UTF-16 (LE)";
//-----------------------------------------------------

the correct BOM should be "\xEF\xBB\xBF"

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

From bugzilla-daemon at llvm.org  Thu Nov 18 02:55:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 02:55:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 8558] TemplateArgumentLoc does not have expression
 field properly set.
In-Reply-To: <bug-8558-206@http.llvm.org/bugs/>
References: <bug-8558-206@http.llvm.org/bugs/>
Message-ID: <20101118085533.208C42A6C12F@llvm.org>

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

Craig Silverstein <csilvers2000 at yahoo.com> changed:

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

--- Comment #3 from Craig Silverstein <csilvers2000 at yahoo.com> 2010-11-18 02:55:32 CST ---
Fixed in revision 119697

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

From bugzilla-daemon at llvm.org  Thu Nov 18 04:45:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 04:45:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 8646] New: Default arguments with more than one
	template
Message-ID: <bug-8646-206@http.llvm.org/bugs/>

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

           Summary: Default arguments with more than one template
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: damienrg+bug at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang++ should compile this code:

template <class T, class U>
struct DefaultParameter
{};

template <class T, class U>
struct Test
{
  Test(const DefaultParameter<T, U> & d = DefaultParameter<T, U>())
  {}
};

int main()
{
  return 0;
}

The current output is:
clang++ produces the following errors:
main.cpp:8:64: error: expected ')'
  Test(const DefaultParameter<T, U> & d = DefaultParameter<T, U>())
                                                               ^
main.cpp:8:7: note: to match this '('
  Test(const DefaultParameter<T, U> & d = DefaultParameter<T, U>())
      ^
main.cpp:8:61: error: expected '>'
  Test(const DefaultParameter<T, U> & d = DefaultParameter<T, U>())
                                                            ^
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  Thu Nov 18 06:09:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 06:09:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 8647] New: getPointerToFunction() hangs in LLVM 2.8
Message-ID: <bug-8647-206@http.llvm.org/bugs/>

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

           Summary: getPointerToFunction() hangs in LLVM 2.8
           Product: new-bugs
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stephenckyle at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I'm having an issue using getPointerToFunction(), where it is hanging
in rare cases.

If I use llvm::CodeGenOpt::None when calling .setOptLevel() on my
EngineBuilder, and add the following Passes to a PassManager:

PM.add(llvm::createInstructionCombiningPass()); // Clean up after IPCP & DAE
PM.add(llvm::createCFGSimplificationPass()); // Clean up after IPCP & DAE
PM.add(llvm::createFunctionInliningPass(255));
PM.add(llvm::createScalarReplAggregatesPass()); // Break up aggregate allocas
PM.add(llvm::createInstructionCombiningPass()); // Cleanup for scalarrepl.
PM.add(llvm::createJumpThreadingPass()); // Thread jumps.
PM.add(llvm::createCFGSimplificationPass()); // Merge & remove BBs
PM.add(llvm::createInstructionCombiningPass()); // Combine silly seq's
PM.add(llvm::createReassociatePass()); // Reassociate expressions
PM.add(llvm::createInstructionCombiningPass());
PM.add(llvm::createMemCpyOptPass()); // Remove memcpy / form memset
PM.add(llvm::createSCCPPass()); // Constant prop with SCCP
PM.add(llvm::createInstructionCombiningPass());
PM.add(llvm::createCorrelatedValuePropagationPass());
PM.add(llvm::createDeadStoreEliminationPass()); // Delete dead stores
PM.add(llvm::createAggressiveDCEPass()); // Delete dead instructions
PM.add(llvm::createCFGSimplificationPass()); // Merge & remove BBs

(You may notice that these are just taken from
createStandardOptimizationPasses(), only with irrelevant ones
removed.)

Then the attached C file is optimised and JITed within a simple test
program which parses the input C file with Clang, calls run() on the
produced Module, gets the relevant function (called LC_0x000012a0() in
this file), and JITs it with getPointerToFunction(). The attached C
was machine-generated (I've removed some extern function calls), but
for 99.999...% of cases the system can JIT any produced C code.

However, if I change llvm::CodeGenOpt::None to
llvm::CodeGenOpt::Default, then getPointerToFunction() will just hang,
unless I also remove PM.add(llvm::createFunctionInliningPass(255));...

This seems to be a regression introduced in LLVM 2.8 - the function
doesn't seem to hang in 2.7.

The easiest way to replicate this is to run:

opt -std-compile-opts bad-c.ll

on the attached bad-c.ll file. This .ll file was created using
llvm::Module.dump(), from the attached bad-c.c file.

You'll notice that if you use the opt built from LLVM 2.7, it completes, but in
LLVM 2.8, it just hangs. I was unsure of whether I could use bugpoint to reduce
this .ll file, as the problem isn't that opt crashes, just that it hangs.

Thanks for looking into this.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 06:48:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 06:48:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 8645] Incorrect UTF-8 BOM while detecting
 unsupported encoding file
In-Reply-To: <bug-8645-206@http.llvm.org/bugs/>
References: <bug-8645-206@http.llvm.org/bugs/>
Message-ID: <20101118124848.0AB8A2A6C12E@llvm.org>

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

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> 2010-11-18 06:48:47 CST ---
Thanks for the report. Fixed in r119698.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 07:21:30 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 07:21:30 -0600 (CST)
Subject: [LLVMbugs] [Bug 8621] error in backend: Unsupported asm: input
 constraint with a matching output constraint of incompatible type!
In-Reply-To: <bug-8621-206@http.llvm.org/bugs/>
References: <bug-8621-206@http.llvm.org/bugs/>
Message-ID: <20101118132130.823C82A6C12E@llvm.org>

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

John Thompson <John.Thompson.JTSoftware at gmail.com> changed:

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

--- Comment #6 from John Thompson <John.Thompson.JTSoftware at gmail.com> 2010-11-18 07:21:29 CST ---
Fixed in r119590.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 07:35:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 07:35:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 8637] ARM backend produces AAPCS-incompatible code
In-Reply-To: <bug-8637-206@http.llvm.org/bugs/>
References: <bug-8637-206@http.llvm.org/bugs/>
Message-ID: <20101118133508.E9E8E2A6C124@llvm.org>

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

Visa Putkinen <yarogami at gmail.com> changed:

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

--- Comment #2 from Visa Putkinen <yarogami at gmail.com> 2010-11-18 07:35:08 CST ---
(In reply to comment #1)
> As you might know there are many different ABIs on ARM. What if you select
> proper target triplet? Say, via llc -mtriple=arm-none-linux-eabi ? Please
> provide .ll file as well.

That did the trick, I had assumed that this would be the default ABI. I knew it
had to be something this simple :). This bug report is invalid.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 10:10:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 10:10:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 5824] clang codegen introduces extra struct copy
 calling function returning struct
In-Reply-To: <bug-5824-206@http.llvm.org/bugs/>
References: <bug-5824-206@http.llvm.org/bugs/>
Message-ID: <20101118161017.0D7502A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #10 from Douglas Gregor <dgregor at apple.com> 2010-11-18 10:10:16 CST ---
Note that we *do* eliminate the memcpy in C, which is goodness.  I'm closing
this bug, and if Daniel or anyone else finds any remaining extraneous struct
copies, we'll open a new bug for that optimization.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 11:07:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 11:07:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 8586] Missing PRE
In-Reply-To: <bug-8586-206@http.llvm.org/bugs/>
References: <bug-8586-206@http.llvm.org/bugs/>
Message-ID: <20101118170758.0736C2A6C12C@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #8 from Dan Gohman <gohman at apple.com> 2010-11-18 11:07:57 CST ---
Fixed in r119704.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 11:16:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 11:16:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 8648] New: Assertion `isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"' failed
Message-ID: <bug-8648-206@http.llvm.org/bugs/>

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

           Summary: Assertion `isa<X>(Val) && "cast<Ty>() argument of
                    incompatible type!"' failed
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: dave at jikos.cz
                CC: llvmbugs at cs.uiuc.edu


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

clang crashes with when analyzing linux kernel/time/clockevents.c:

ANALYZE: kernel/time/clockevents.c clockevents_program_event
clang:
/usr/src/packages/BUILD/llvm-2.9svn119697/include/llvm/Support/Casting.h:202:
typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
clang::Loc, Y
 = clang::SVal, typename llvm::cast_retty<To, From>::ret_type = clang::Loc&]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
0  clang           0x0000000001877d0f
1  clang           0x00000000018784ba
2  libpthread.so.0 0x00002b8d0b4ea2e0
3  libc.so.6       0x00002b8d0c0a79e5 gsignal + 53
4  libc.so.6       0x00002b8d0c0a8ee6 abort + 390
5  libc.so.6       0x00002b8d0c0a0235 __assert_fail + 245
6  clang           0x0000000000ca1b0a
clang::StoreManager::getLValueFieldOrIvar(clang::Decl const*, clang::SVal) +
282
7  clang           0x0000000000bc8c10
clang::StoreManager::getLValueField(clang::FieldDecl const*, clang::SVal) + 32
8  clang           0x0000000000c2c26a
clang::GRExprEngine::VisitMemberExpr(clang::MemberExpr const*,
clang::ExplodedNode*, clang::ExplodedNodeSet&, bool) + 522
9  clang           0x0000000000c2c906 clang::GRExprEngine::Visit(clang::Stmt
const*, clang::ExplodedNode*, clang::ExplodedNodeSet&) + 1382
10 clang           0x0000000000c31403
clang::GRExprEngine::VisitBinaryOperator(clang::BinaryOperator const*,
clang::ExplodedNode*, clang::ExplodedNodeSet&, bool) + 771
11 clang           0x0000000000c2ccf9 clang::GRExprEngine::Visit(clang::Stmt
const*, clang::ExplodedNode*, clang::ExplodedNodeSet&) + 2393
12 clang           0x0000000000c34b86
clang::GRExprEngine::ProcessStmt(clang::CFGStmt, clang::GRStmtNodeBuilder&) +
870
13 clang           0x0000000000c352d8
clang::GRExprEngine::ProcessElement(clang::CFGElement,
clang::GRStmtNodeBuilder&) + 56
14 clang           0x0000000000c21354
clang::GRCoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int,
clang::ExplodedNode*) + 196
15 clang           0x0000000000c222cd
clang::GRCoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned
int, clang::GRState const*) + 749
16 clang           0x0000000000ba9337
17 clang           0x0000000000ba8541
18 clang           0x0000000000ba8e33
19 clang           0x0000000000945ded clang::ParseAST(clang::Sema&, bool) + 301
20 clang           0x00000000006de265
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
21 clang           0x00000000006bcc5a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1274
22 clang           0x00000000006b3cf8 cc1_main(char const**, char const**, char
const*, void*) + 664
23 clang           0x00000000006bbc69 main + 4057
24 libc.so.6       0x00002b8d0c093b7d __libc_start_main + 253
25 clang           0x00000000006b3859
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1
-DIBOutlet=__attribute__((iboutlet)) -cc1 -triple x86_64-unknown-linux-gnu
-fsyntax-only -disable-free -main-file-name clockeven
ts.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
11.3 -nostdinc -resource-dir /us
r/bin/../lib/clang/2.9 -isystem /usr/lib64/gcc/x86_64-suse-linux/4.5/include
-include include/generated/autoconf.h -D __KERNEL__ -D CONFIG_AS_CFI=1 -D
CONFIG_AS_CFI_SIGNAL_FRA
ME=1 -D CONFIG_AS_CFI_SECTIONS=1 -D CONFIG_AS_FXSAVEQ=1 -D CC_HAVE_ASM_GOTO -D
KBUILD_STR(s)=#s -D KBUILD_BASENAME=KBUILD_STR(clockevents) -D
KBUILD_MODNAME=KBUILD_STR(clockev
ents) -I /home/dsterba/_kernel/linux-2.6/arch/x86/include -I include
-Wno-trigraphs -Wno-format-security -Wno-sign-compare -Wno-pointer-sign
-ferror-limit 19 -fmessage-length
0 -fgnu-runtime -fdiagnostics-show-option -x c kernel/time/clockevents.c
-analyze -analyzer-display-progress -analyzer-eagerly-assume
-analyzer-opt-analyze-nested-blocks -anal
yzer-check-objc-mem -analyzer-check-idempotent-operations
-analyzer-check-security-syntactic -analyzer-check-dead-stores
-analyzer-check-objc-unused-ivars -analyzer-check-objc
-methodsigs -analyzer-store=region -analyzer-constraints=range
-analyzer-output=html -o
/home/dsterba/_kernel/linux-2.6/SCAN-allno/2010-11-18-1
1.      <eof> parser at end of file
2.      kernel/time/clockevents.c:115:2: Error evaluating statement
3.      kernel/time/clockevents.c:115:2: Error evaluating statement
4.      kernel/time/clockevents.c:115:10
<Spelling=include/linux/ktime.h:131:28>: Error evaluating statement


clang svn version: 119697

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

From bugzilla-daemon at llvm.org  Thu Nov 18 14:04:25 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 14:04:25 -0600 (CST)
Subject: [LLVMbugs] [Bug 6942] __vector bool int
In-Reply-To: <bug-6942-206@http.llvm.org/bugs/>
References: <bug-6942-206@http.llvm.org/bugs/>
Message-ID: <20101118200425.9BB182A6C12D@llvm.org>

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

John Thompson <John.Thompson.JTSoftware at gmail.com> changed:

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

--- Comment #2 from John Thompson <John.Thompson.JTSoftware at gmail.com> 2010-11-18 14:04:25 CST ---
Anton Yartsev fixed this.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 14:09:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 14:09:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 8622] Assertion `currentLoop->isLCSSAForm(*DT)'
	failed.
In-Reply-To: <bug-8622-206@http.llvm.org/bugs/>
References: <bug-8622-206@http.llvm.org/bugs/>
Message-ID: <20101118200904.D592E2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2010-11-18 14:09:04 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20101115/112107.html

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

From bugzilla-daemon at llvm.org  Thu Nov 18 15:35:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 15:35:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 8649] New: clang assertion: SmallVector overflow
 compiling template code
Message-ID: <bug-8649-206@http.llvm.org/bugs/>

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

           Summary: clang assertion: SmallVector overflow compiling
                    template code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


$ clang++ -v
clang version 2.9 (trunk 119741)
Target: x86_64-apple-darwin10
Thread model: posix


$ clang++ -O3  -fno-exceptions -fno-rtti -fno-common -m64 -c -x c++ crash.ii
Assertion failed: (begin() + idx < end()), function operator[], file
/Volumes/Data/g/llvm/include/llvm/ADT/SmallVector.h, line 149.
0  clang             0x0000000100f86df2 std::vector<llvm::sys::Path,
std::allocator<llvm::sys::Path>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::sys::Path*,
std::vector<llvm::sys::Path, std::allocator<llvm::sys::Path> > >,
llvm::sys::Path const&) + 8850
1  clang             0x0000000100f87399 std::vector<llvm::sys::Path,
std::allocator<llvm::sys::Path>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::sys::Path*,
std::vector<llvm::sys::Path, std::allocator<llvm::sys::Path> > >,
llvm::sys::Path const&) + 10297
2  libSystem.B.dylib 0x00007fff8320f67a _sigtramp + 26
3  clang             0x00000001003de7ac
llvm::SmallVectorImpl<clang::TargetInfo::ConstraintInfo>::~SmallVectorImpl() +
7740
4  clang             0x0000000100019a66
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&) + 3606
5  clang             0x0000000100019a28
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&) + 3544
6  clang             0x00000001004142f2 clang::TemplateArgumentLoc*
std::__uninitialized_copy_aux<clang::TemplateArgumentLoc const*,
clang::TemplateArgumentLoc*>(clang::TemplateArgumentLoc const*,
clang::TemplateArgumentLoc const*, clang::TemplateArgumentLoc*,
std::__false_type) + 20850
7  clang             0x00000001004180c9 clang::TemplateArgumentLoc*
std::__uninitialized_copy_aux<clang::TemplateArgumentLoc const*,
clang::TemplateArgumentLoc*>(clang::TemplateArgumentLoc const*,
clang::TemplateArgumentLoc const*, clang::TemplateArgumentLoc*,
std::__false_type) + 36681
8  clang             0x000000010040f3c0 clang::TemplateArgumentLoc*
std::__uninitialized_copy_aux<clang::TemplateArgumentLoc const*,
clang::TemplateArgumentLoc*>(clang::TemplateArgumentLoc const*,
clang::TemplateArgumentLoc const*, clang::TemplateArgumentLoc*,
std::__false_type) + 576
9  clang             0x0000000100420d65 clang::DeducedTemplateArgument*
std::__uninitialized_copy_aux<clang::DeducedTemplateArgument const*,
clang::DeducedTemplateArgument*>(clang::DeducedTemplateArgument const*,
clang::DeducedTemplateArgument const*, clang::DeducedTemplateArgument*,
std::__false_type) + 29301
10 clang             0x0000000100444edf
clang::Redeclarable<clang::TypedefDecl>::setPreviousDeclaration(clang::TypedefDecl*)
+ 30527

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

From bugzilla-daemon at llvm.org  Thu Nov 18 15:52:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 15:52:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8482] arm_neon.h contains wrong definition of vshl
In-Reply-To: <bug-8482-206@http.llvm.org/bugs/>
References: <bug-8482-206@http.llvm.org/bugs/>
Message-ID: <20101118215235.E93312A6C124@llvm.org>

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

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

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

--- Comment #3 from Bob Wilson <bob.wilson at apple.com> 2010-11-18 15:52:35 CST ---
Fixed with llvm svn r119742 and clang svn r119748.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 17:18:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 17:18:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8650] New: no implicit conversion in template values
Message-ID: <bug-8650-206@http.llvm.org/bugs/>

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

           Summary: no implicit conversion in template values
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: marc.glisse at normalesup.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This code (from libstdc++ in gcc-4.2) fails to compile. Is it on purpose?

template<bool, typename> struct enable_if {};
template<typename T> struct enable_if<true,T> {
 typedef T type;
};
template<typename _Tp, int _Nm> struct array {
 void at(int n) {
  _M_check<_Nm>(n);
 }
 template<int _Mm> typename enable_if<_Mm, void>::type _M_check(int) const { }
 // template<int _Mm> typename enable_if<_Mm!=0, void>::type _M_check(int)
const { }
};
int main(){
 array<double,3> a;
 a.at(0);
}


bug.cpp:7:3: error: no matching member function for call to '_M_check'
  _M_check<_Nm>(n);
  ^~~~~~~~~~~~~
bug.cpp:14:4: note: in instantiation of member function 'array<double, 3>::at'
requested here
 a.at(0);
   ^
bug.cpp:9:56: note: candidate template ignored: substitution failure [with _Mm
= 3]
 template<int _Mm> typename enable_if<_Mm, void>::type _M_check(int) const { }
                                                       ^

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

From bugzilla-daemon at llvm.org  Thu Nov 18 18:49:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 18:49:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 8111] FoldingSetNodeID::AddString and endianness
In-Reply-To: <bug-8111-206@http.llvm.org/bugs/>
References: <bug-8111-206@http.llvm.org/bugs/>
Message-ID: <20101119004926.200E02A6C12C@llvm.org>

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

Dale Johannesen <dalej at apple.com> changed:

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

--- Comment #1 from Dale Johannesen <dalej at apple.com> 2010-11-18 18:49:25 CST ---
Looks good to me, checked in as 119770.

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

From bugzilla-daemon at llvm.org  Thu Nov 18 21:24:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 18 Nov 2010 21:24:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8546] CMake/MSVS: Don't be bothered with dialogs of
 updating project files on Visual Studio
In-Reply-To: <bug-8546-206@http.llvm.org/bugs/>
References: <bug-8546-206@http.llvm.org/bugs/>
Message-ID: <20101119032446.5B9652A6C12D@llvm.org>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |REMIND
         AssignedTo|unassignedbugs at nondot.org   |geek4civic at gmail.com

--- Comment #8 from NAKAMURA Takumi <geek4civic at gmail.com> 2010-11-18 21:24:45 CST ---
Committed in r119780.

Should I leave this open until future CMake would have a solution?

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

From bugzilla-daemon at llvm.org  Fri Nov 19 04:02:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Nov 2010 04:02:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 8651] New: Terrible diagnostics if namespace
 omitted on constructor parameter
Message-ID: <bug-8651-206@http.llvm.org/bugs/>

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

           Summary: Terrible diagnostics if namespace omitted on
                    constructor parameter
           Product: clang
           Version: unspecified
          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


I was writing this class:

class RenameMethodConsumer : public clang::ASTConsumer {
  clang::Rewriter rewriter_;
  clang::ASTContext* context_;
 public:
  RenameMethodConsumer(ASTContext* context) : context_(context) {}
};

I should've written `clang::ASTContext` in the constructor, but failed to do
so. Here's clang's error:


macintosh-3:clangtut nico$ CXX=/Users/nico/src/llvm-2.8/Release/bin/clang++ 
make tut_rewrite
/Users/nico/src/llvm-2.8/Release/bin/clang++
-I/Users/nico/src/llvm-2.8/tools/clang/include -fno-rtti
`/Users/nico/src/llvm-2.8/Release/bin/llvm-config --cxxflags`   -c -o
tut_rewrite.o tut_rewrite.cpp
tut_rewrite.cpp:38:34: error: expected ')'
  RenameMethodConsumer(ASTContext* context) : context_(context) {}
                                 ^
tut_rewrite.cpp:38:23: note: to match this '('
  RenameMethodConsumer(ASTContext* context) : context_(context) {}
                      ^
tut_rewrite.cpp:38:47: error: invalid use of nonstatic data member 'context_'
  RenameMethodConsumer(ASTContext* context) : context_(context) {}
                                              ^~~~~~~~
tut_rewrite.cpp:38:24: error: field has incomplete type 'RenameMethodConsumer'
  RenameMethodConsumer(ASTContext* context) : context_(context) {}
                       ^
tut_rewrite.cpp:34:7: note: definition of 'RenameMethodConsumer' is not
complete until the closing '}'
class RenameMethodConsumer : public clang::ASTConsumer {
      ^
tut_rewrite.cpp:38:67: error: expected ';' at end of declaration list
  RenameMethodConsumer(ASTContext* context) : context_(context) {}
                                                                  ^
                                                                  ;
4 errors generated.
make: *** [tut_rewrite.o] Error 1


Here's what gcc does:

g++ -I/Users/nico/src/llvm-2.8/tools/clang/include -fno-rtti
`/Users/nico/src/llvm-2.8/Release/bin/llvm-config --cxxflags`   -c -o
tut_rewrite.o tut_rewrite.cpp
tut_rewrite.cpp:38: error: expected `)' before ?*? token
tut_rewrite.cpp: In function ?int main(int, char**)?:
tut_rewrite.cpp:106: error: no matching function for call to
?RenameMethodConsumer::RenameMethodConsumer(clang::ASTContext*)?
tut_rewrite.cpp:34: note: candidates are:
RenameMethodConsumer::RenameMethodConsumer()
tut_rewrite.cpp:34: note:                
RenameMethodConsumer::RenameMethodConsumer(const RenameMethodConsumer&)
make: *** [tut_rewrite.o] Error 1

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

From bugzilla-daemon at llvm.org  Fri Nov 19 06:00:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Nov 2010 06:00:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 8225] [Unit Test][JITTest] Failure: Unable to
 resolve externals.
In-Reply-To: <bug-8225-206@http.llvm.org/bugs/>
References: <bug-8225-206@http.llvm.org/bugs/>
Message-ID: <20101119120000.5DFB12A6C12D@llvm.org>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #3 from NAKAMURA Takumi <geek4civic at gmail.com> 2010-11-19 05:59:59 CST ---
Fixed in r119783!

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

From bugzilla-daemon at llvm.org  Fri Nov 19 15:22:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Nov 2010 15:22:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 8652] New: -fno-elide-constructors doesn't prevent
	all elisions
Message-ID: <bug-8652-206@http.llvm.org/bugs/>

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

           Summary: -fno-elide-constructors doesn't prevent all elisions
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: reid.kleckner at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I was drafting up a quiz question about C++ copy constructors of the form
"given this program, what does it print?" where the copy ctor keeps a counter
for the number of calls it gets.  The point is that copying objects can be
slow, and it's easy to write C++ code that does it if you're not careful. 
However, I need to be careful because there are circumstances in which a copy
ctor call can be elided by the standard, even if it has side-effects.

Interestingly, both clang and gcc elide copy constructors regardless of the
optimization level, which is not what I expected.  I discovered that gcc has
the -fno-elide-constructors option, which I used to check if my example had
elidable copy constructors by comparing the output of the program with and
without elision.  Clang has the same option, but it doesn't seem to work when
applied to my small sample program:

[rnk at methacholine quiz2]$ cat elision.cpp 
#include <iostream>

static int copies = 0;

struct CopyCounter {
  CopyCounter() { }
  CopyCounter(const CopyCounter &obj) {
    copies++;
  }
};

CopyCounter foo() {
  return CopyCounter();
}

int main(int argc, char **argv) {
  CopyCounter a(foo());
  std::cout << copies << '\n';
  return 0;
}
[rnk at methacholine quiz2]$ g++ elision.cpp -o elision && ./elision 
0
[rnk at methacholine quiz2]$ g++ -fno-elide-constructors elision.cpp -o elision &&
./elision 
2
[rnk at methacholine quiz2]$ clang++ elision.cpp -o elision && ./elision 
0
[rnk at methacholine quiz2]$ clang++ -fno-elide-constructors elision.cpp -o
elision && ./elision 
0

Is this a bug?  Is clang missing a check for LangOpts::ElideConstructors
somewhere in CodeGen?

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

From bugzilla-daemon at llvm.org  Fri Nov 19 15:34:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 19 Nov 2010 15:34:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 8653] New: ObjC++ synthesized property setter uses
 GetCopyStructFn
Message-ID: <bug-8653-206@http.llvm.org/bugs/>

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

           Summary: ObjC++ synthesized property setter uses
                    GetCopyStructFn
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jbenet at cs.stanford.edu
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Hello Everyone, 

Please excuse any breaches of protocol, this is my first time posting here.

If you look at CodeGen/CGObjC.cpp
(http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjC.cpp?view=markup
for quickness), within CodeGenFunction::GenerateObjCSetter, the second branch
of the if ends with:

EmitCall(Types.getFunctionInfo(getContext().VoidTy, Args,
FunctionType::ExtInfo()),
             GetCopyStructFn, ReturnValueSlot(), Args);

I believe this is incorrect. In the C world, memcpying the struct is perfectly
fine. But in ObjectiveC++, this means that no constructor gets called. This is
very damaging to any code that requires per-instance execution in the
constructor. Allow me to give you a very concrete example:

Consider the case of smart pointers. Constructors and assignment operator call
refIncrement, and destructor calls refDecrement. There is a big problem using
synthesized setter thus:

someNSObject.aSmartPtr = somePtr;

Neither the copy constructor or the assignment operator will be called on the
Ivar, and only the memory will be copied over. This causes one refIncrement to
be missed, making the count one less than it ought to be. 

Yuji's answer to this stack overflow question
http://stackoverflow.com/questions/3642979, has a simple implementation of this
behavior in action.

I asked about this in the IRC channel earlier and was advised to submit a bug
report, so here it is.

I tried to find a viable solution, and offhand (knowing almost nothing of
Clang's architecture) i would say that a call to getSetterCXXAssignment() (like
the third branch of the if statement) is in order.

In fact, a workaround is to force the execution of the third branch (by
declaring the property nonatomic, failing the first condition of the 2nd if),
however this is not a good solution, because library code (as smart pointers
are) will not be widely used if it has such a strong constraint.

Anyway, I hope that this can be resolved soon. It shouldn't take a lot of time,
and I'd be willing to contribute. 

Thanks for building great software!
Cheers!

Juan

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

From bugzilla-daemon at llvm.org  Sat Nov 20 06:34:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Nov 2010 06:34:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 8589] Wrong atomic intrinsic codegen at -O0
In-Reply-To: <bug-8589-206@http.llvm.org/bugs/>
References: <bug-8589-206@http.llvm.org/bugs/>
Message-ID: <20101120123459.C6A552A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2010-11-20 06:34:59 CST ---
This now seems to work correctly.

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

From bugzilla-daemon at llvm.org  Sat Nov 20 15:06:18 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Nov 2010 15:06:18 -0600 (CST)
Subject: [LLVMbugs] [Bug 8654] New: clang-as-a-library's preprocessor
 doesn't trigger Elif, Else and Endif callbacks at the right times
Message-ID: <bug-8654-206@http.llvm.org/bugs/>

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

           Summary: clang-as-a-library's preprocessor doesn't trigger
                    Elif, Else and Endif callbacks at the right times
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5806)
 --> (http://llvm.org/bugs/attachment.cgi?id=5806)
Proposed fix

'dsturtevant' on IRC pointed out that PPCallbacks::Elif, Else and Endif aren't
called if they terminate a preprocessor block which is being skipped due to an
earlier #if or #elif not matching. For instance:

#if 0 // If()
#else // Else() MISSED
#endif // Endif()

#if 0 // If()
#elif 1 // Elif() MISSED
#else // Endif()

#if 0 // If()
#endif // Endif() MISSED

I've put together a patch which should fix this but it's untested (there don't
seem to be any tests of the PPCallbacks stuff to model such a test on).

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

From bugzilla-daemon at llvm.org  Sat Nov 20 15:10:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Nov 2010 15:10:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 8655] New: clang + compiler-rt requires an arm
 assembler to build on Darwin
Message-ID: <bug-8655-206@http.llvm.org/bugs/>

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

           Summary: clang + compiler-rt requires an arm assembler to build
                    on Darwin
           Product: compiler-rt
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


I tried building compiler-rt as part of the clang build by placing it in
llvm/projects.

The build failed because I don't have an arm assembler installed on my Snow
Leopard system:

  ARCHIVE:   clang_darwin/eprintf/i386:
/Volumes/Krask/b/tools/clang/runtime/clang_darwin/eprintf/i386/libcompiler_rt.a
  FINAL-ARCHIVE: clang_darwin/eprintf:
/Volumes/Krask/b/tools/clang/runtime/clang_darwin/eprintf/libcompiler_rt.a
  ARCHIVE:   clang_darwin/10.4/i386:
/Volumes/Krask/b/tools/clang/runtime/clang_darwin/10.4/i386/libcompiler_rt.a
  ARCHIVE:   clang_darwin/10.4/x86_64:
/Volumes/Krask/b/tools/clang/runtime/clang_darwin/10.4/x86_64/libcompiler_rt.a
  FINAL-ARCHIVE: clang_darwin/10.4:
/Volumes/Krask/b/tools/clang/runtime/clang_darwin/10.4/libcompiler_rt.a
  ASSEMBLE:  clang_darwin/armv6/armv6:
/Volumes/Krask/g/llvm/projects/compiler-rt/lib/arm/restore_vfp_d8_d15_regs.S
/usr/libexec/gcc/i686-apple-darwin10/4.2.1/as: assembler
(/usr/bin/../libexec/gcc/darwin/arm/as or
/usr/bin/../local/libexec/gcc/darwin/arm/as) for architecture arm not installed
Installed assemblers are:
/usr/bin/../libexec/gcc/darwin/ppc64/as for architecture ppc64
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
/usr/bin/../libexec/gcc/darwin/ppc/as for architecture ppc
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)
make[4]: ***
[/Volumes/Krask/b/tools/clang/runtime/clang_darwin/armv6/armv6/SubDir.lib__arm/restore_vfp_d8_d15_regs.o]
Error 1
make[3]: *** [BuildRuntimeLibraries] Error 2
make[2]: *** [all] Error 1
make[1]: *** [clang/.makeall] Error 2
make: *** [all] Error 1

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

From bugzilla-daemon at llvm.org  Sat Nov 20 16:18:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Nov 2010 16:18:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 8656] New: MC miscompiles CALL to absolute address
 on X86-32 ELF
Message-ID: <bug-8656-206@http.llvm.org/bugs/>

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

           Summary: MC miscompiles CALL to absolute address on X86-32 ELF
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pdox at google.com
                CC: llvmbugs at cs.uiuc.edu


----REPRODUCING THE PROBLEM----

Download test.c and run:

llvm-gcc -emit-llvm -S test.c -o test.ll
llc -march=x86 -mcpu=pentium4 -mtriple="i686-none-linux-gnu"  -filetype=asm
test.ll -o test.s
llvm-mc -assemble -filetype=obj -arch=i686 -triple=i686-none-linux-gnu test.s
-o test.o

You will get an assertion or segmentation fault.

Alternatively, use direct object emission:

llc -march=x86 -mcpu=pentium4 -mtriple="i686-none-linux-gnu"  -filetype=obj
test.ll -o test.o

The command will succeed, but if you examine test.o (e.g. with objdump) you
will find that the generated call is incorrect.

----EXPLANATION----

In C code, we can generate a call to an absolute address. For example:

    // Call function at 0x1000
    ((void(*)())0x1000)();

This is useful for low-level system programming.  The above compiles to
bitcode:

    call void (...)* inttoptr (i64 4096 to void (...)*)() nounwind

Running llc for X86-32 ELF with assembly output emits:

    calll 4096

Note that the IA-32 instruction set does not actually have a form of the call
instruction that can call an absolute address. When using ELF, however, the
above operation can be emitted as a 32-bit PC-relative call with a relocation
which computes the value 4096 - PC.

For example, with binutils gas, "calll 4096" is correctly assembled to:

      13:    e8 fc 0f 00 00              call   1014 <main+0x1014>

With relocation:

    00000014 R_386_PC32        *ABS*


However, with llvm-mc, "calll 4096" generates an assertion or segmentation
fault in ELFObjectWriter::IsFixupFullyResolved. This function does not expect a
PC-relative Fixup that has no symbols. It tries to dereference getSymA() which
is NULL.

Something different but also wrong happens when you use direct object emission
(llc -filetype=obj).

In this case, the assembling happens successfully, but the resulting object
file contains: 

  13:    e8 00 10 00 00           call   1018 <main+0x1018>

With no relocation, which means it will actually call PC+4096, instead of
absolute address 4096.

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

From bugzilla-daemon at llvm.org  Sat Nov 20 18:10:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Nov 2010 18:10:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 8652] -fno-elide-constructors doesn't prevent all
	elisions
In-Reply-To: <bug-8652-206@http.llvm.org/bugs/>
References: <bug-8652-206@http.llvm.org/bugs/>
Message-ID: <20101121001028.CE4BE2A6C12D@llvm.org>

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

Anders Carlsson <andersca at mac.com> changed:

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

--- Comment #1 from Anders Carlsson <andersca at mac.com> 2010-11-20 18:10:28 CST ---
Turns out we were just not passing along the command to clang -cc1. Fixed in 

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20101115/036641.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  Sat Nov 20 18:29:11 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Nov 2010 18:29:11 -0600 (CST)
Subject: [LLVMbugs] [Bug 8644] [memcpyopt] not optimizing away memcpy
 feeding byval [aka PR2140?]
In-Reply-To: <bug-8644-206@http.llvm.org/bugs/>
References: <bug-8644-206@http.llvm.org/bugs/>
Message-ID: <20101121002911.B15CD2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-11-20 18:29:11 CST ---
Implemented in r119916.

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

From bugzilla-daemon at llvm.org  Sat Nov 20 18:51:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 20 Nov 2010 18:51:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 8656] MC miscompiles CALL to absolute address on
	X86-32 ELF
In-Reply-To: <bug-8656-206@http.llvm.org/bugs/>
References: <bug-8656-206@http.llvm.org/bugs/>
Message-ID: <20101121005149.8E4912A6C12E@llvm.org>

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

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

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

--- Comment #5 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-20 18:51:49 CST ---
At least the .s -> .o path is fixed in r119917. Please open another bug if you
find something in the .bc -> .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  Sun Nov 21 01:36:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 01:36:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 8657] New: DSE doesn't remove small stores
 overwritten by later large ones
Message-ID: <bug-8657-206@http.llvm.org/bugs/>

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

           Summary: DSE doesn't remove small stores overwritten by later
                    large ones
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


>From PR8576:

Partial must def case -- gcc cleans up all the stores except the last one --
but LLVM does none:

union U {
  struct C
   {
      char c[4];
   }cc;

   int ii;
} u ;

void foo(int i)
{
   u.cc.c[0] = 10; // Dead
   u.cc.c[1] = 10; // Dead too
   u.cc.c[i] = 10; // Dead too
   u.ii  = 20;
}

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

From bugzilla-daemon at llvm.org  Sun Nov 21 01:37:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 01:37:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 8576] Missing dead store elimination
In-Reply-To: <bug-8576-206@http.llvm.org/bugs/>
References: <bug-8576-206@http.llvm.org/bugs/>
Message-ID: <20101121073712.166932A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-11-21 01:37:11 CST ---
Testcases in Comment #1/2 are implemented in r119927, thanks!

I'll split the last case out to PR8657, since it is a separate issue.

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

From bugzilla-daemon at llvm.org  Sun Nov 21 02:19:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 02:19:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 8524] [inline asm] spandsp compilation failure
In-Reply-To: <bug-8524-206@http.llvm.org/bugs/>
References: <bug-8524-206@http.llvm.org/bugs/>
Message-ID: <20101121081920.C80002A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #10 from Chris Lattner <clattner at apple.com> 2010-11-21 02:19:20 CST ---
Implemented in r119931, 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  Sun Nov 21 02:20:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 02:20:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 8513] Assertion `From != To &&
 "ReplaceAndSimplifyAllUses(X, X) is not valid!"' failed
In-Reply-To: <bug-8513-206@http.llvm.org/bugs/>
References: <bug-8513-206@http.llvm.org/bugs/>
Message-ID: <20101121082005.18E2C2A6C130@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-11-21 02:20:04 CST ---
Yep, 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  Sun Nov 21 02:29:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 02:29:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 8420] MachineInstr constructor does not correctly
 duplicate AsmPrinterFlags
In-Reply-To: <bug-8420-206@http.llvm.org/bugs/>
References: <bug-8420-206@http.llvm.org/bugs/>
Message-ID: <20101121082934.76F1A2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-21 02:29:34 CST ---
This is correct behavior.  These flags have unknown semantics to target
independent code, so copying them may not be 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  Sun Nov 21 02:31:08 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 02:31:08 -0600 (CST)
Subject: [LLVMbugs] [Bug 8417] MachineInstr does not have clear AsmPrinter
 flag instructions
In-Reply-To: <bug-8417-206@http.llvm.org/bugs/>
References: <bug-8417-206@http.llvm.org/bugs/>
Message-ID: <20101121083108.84FF62A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-21 02:31:08 CST ---
Corrected patch applied in r119932, 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  Sun Nov 21 02:39:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 02:39:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 8268] constant folder misses negative GEP
In-Reply-To: <bug-8268-206@http.llvm.org/bugs/>
References: <bug-8268-206@http.llvm.org/bugs/>
Message-ID: <20101121083957.1C1912A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-11-21 02:39:56 CST ---
Fix applied in r119933, thanks Dan.

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

From bugzilla-daemon at llvm.org  Sun Nov 21 02:40:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 02:40:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 8197] undefined symbol:
	LLVMInitializeMBlazeTargetInfo
In-Reply-To: <bug-8197-206@http.llvm.org/bugs/>
References: <bug-8197-206@http.llvm.org/bugs/>
Message-ID: <20101121084038.580FB2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-11-21 02:40:36 CST ---
I'm assuming that this old bug got fixed.

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

From bugzilla-daemon at llvm.org  Sun Nov 21 02:42:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 02:42:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 8094] clang hangs while compiling PHP
In-Reply-To: <bug-8094-206@http.llvm.org/bugs/>
References: <bug-8094-206@http.llvm.org/bugs/>
Message-ID: <20101121084248.650932A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-11-21 02:42:47 CST ---
Dan fixed this recently, this now completes in a reasonable amount of time at
-O3.

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

From bugzilla-daemon at llvm.org  Sun Nov 21 10:06:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 10:06:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 8658] New: clang doesn't ignore '/' comments in
 assemler .s files
Message-ID: <bug-8658-206@http.llvm.org/bugs/>

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

           Summary: clang doesn't ignore '/' comments in assemler .s files
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ojab at ojab.ru
                CC: llvmbugs at cs.uiuc.edu


There is many errors like

./libs/js/nsprpub/pr/src/md/unix/os_Linux_x86_64.s:1:1: error: unexpected token
at start of statement
/ -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*-
^
./libs/js/nsprpub/pr/src/md/unix/os_Linux_x86_64.s:1:27: error: unexpected
token in argument list
/ -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*-


during nspr build, os_Linux_x86_64.s can be found in the attached file. GNU as
builds it just fine.

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

From bugzilla-daemon at llvm.org  Sun Nov 21 12:35:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 12:35:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 8641] Clang incorrectly warns of undefined behavior
 with printf specifier %#X
In-Reply-To: <bug-8641-206@http.llvm.org/bugs/>
References: <bug-8641-206@http.llvm.org/bugs/>
Message-ID: <20101121183512.C6D2D2A6C12E@llvm.org>

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

Anders Carlsson <andersca at mac.com> changed:

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

--- Comment #2 from Anders Carlsson <andersca at mac.com> 2010-11-21 12:35:12 CST ---
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20101115/036657.html

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

From bugzilla-daemon at llvm.org  Sun Nov 21 20:44:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 20:44:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 8659] New: tcmalloc in Chromium segfaults when
 compiled with both -fPIC and integrated-as
Message-ID: <bug-8659-206@http.llvm.org/bugs/>

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

           Summary: tcmalloc in Chromium segfaults when compiled with both
                    -fPIC and integrated-as
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chromium at hybridsource.org
                CC: llvmbugs at cs.uiuc.edu


integrated-as was turned on by default in Chromium this week
(http://crrev.com/66265), but Chromium trunk built with clang trunk 119910
segfaults right away when run on FreeBSD amd64.  If I compile with clang using
no-integrated-as, Chromium works fine with the system GNU assembler. 
Alternately, removing the -fPIC flag from the tcmalloc component alone also
fixes the problem.  Since -fPIC doesn't pose a problem for the GNU assembler,
this is probably a bug in clang's integrated-as that is somehow surfaced by
tcmalloc, as the rest of Chromium compiles fine with the -fPIC/integrated-as
combo.  Let me know what other info might help reduce this problem.

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

From bugzilla-daemon at llvm.org  Sun Nov 21 22:51:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 21 Nov 2010 22:51:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 8660] New: C API is lacking useful features
 available in the C++ API
Message-ID: <bug-8660-206@http.llvm.org/bugs/>

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

           Summary: C API is lacking useful features available in the C++
                    API
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: endobson at mac.com
                CC: llvmbugs at cs.uiuc.edu


There are many useful features that are lacking in the C API. Currently the
ones that I would like added are getting a ContextRef from a ModuleRef, and
functions for linking two or more modules together. While I can see not having
everything in the C API, having enough so that it is usable would be useful.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 04:29:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 04:29:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 8661] New: SourceRange on CXXNewExprs is sometimes
	wrong
Message-ID: <bug-8661-206@http.llvm.org/bugs/>

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

           Summary: SourceRange on CXXNewExprs is sometimes wrong
           Product: clang
           Version: unspecified
          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


See this thread
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-November/012159.html for
discussion.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 04:31:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 04:31:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 8661] SourceRange on CXXNewExprs is sometimes wrong
In-Reply-To: <bug-8661-206@http.llvm.org/bugs/>
References: <bug-8661-206@http.llvm.org/bugs/>
Message-ID: <20101122103107.7B6732A6C12D@llvm.org>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #1 from Nico Weber <nicolasweber at gmx.de> 2010-11-22 04:31:07 CST ---
r119966

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

From bugzilla-daemon at llvm.org  Mon Nov 22 05:06:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 05:06:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8662] New: "Try to highlight whitespace" assertion
 in invalid code
Message-ID: <bug-8662-206@http.llvm.org/bugs/>

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

           Summary: "Try to highlight whitespace" assertion in invalid
                    code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=5813)
 --> (http://llvm.org/bugs/attachment.cgi?id=5813)
Asserting testcase, with space at end of line.

The attached file leads to the following assertion. Note that the file has a
space at the end of the line -- this is necessary to get the assertion.

t.bashed.902.cc:1:27: error: expected '}'
template<template<struct{ 
                          ^
t.bashed.902.cc:1:25: note: to match this '{'
template<template<struct{ 
                        ^
t.bashed.902.cc:1:26: error: expected ';' after struct
template<template<struct{ 
                         ^
                         ;
t.bashed.902.cc:1:27: error: a non-type template parameter cannot have type
'struct <anonymous struct at t.bashed.902.cc:1:19>'
template<template<struct{ 
                          ^
t.bashed.902.cc:1:27: error: expected ',' or '>' in template-parameter-list
t.bashed.902.cc:1:27: error: expected 'class' before ''
t.bashed.902.cc:1:27: error: expected ',' or '>' in template-parameter-list
t.bashed.902.cc:1:27: warning: declaration does not declare anything
[-Wmissing-declarations]
clang: TextDiagnosticPrinter.cpp:144: void
clang::TextDiagnosticPrinter::HighlightRange(const clang::CharSourceRange&,
const clang::SourceManager&, unsigned int, clang::FileID, std::string&, const
std::string&): Assertion `StartColNo <= EndColNo && "Trying to highlight
whitespace??"' failed.
0  clang           0x00000000016a2fcf
1  clang           0x00000000016a5242
2  libpthread.so.0 0x00007fbaf25c88f0
3  libc.so.6       0x00007fbaf18b7a75 gsignal + 53
4  libc.so.6       0x00007fbaf18bb5c0 abort + 384
5  libc.so.6       0x00007fbaf18b0941 __assert_fail + 241
6  clang           0x00000000006896ba
clang::TextDiagnosticPrinter::HighlightRange(clang::CharSourceRange const&,
clang::SourceManager const&, unsigned int, clang::FileID, std::string&,
std::string const&) + 1370
7  clang           0x000000000068a858
clang::TextDiagnosticPrinter::EmitCaretDiagnostic(clang::SourceLocation,
clang::CharSourceRange*, unsigned int, clang::SourceManager const&,
clang::FixItHint const*, unsigned int, unsigned int, unsigned int, unsigned
int, unsigned int) + 3928
8  clang           0x000000000068bdad
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::Diagnostic::Level,
clang::DiagnosticInfo const&) + 2093
9  clang           0x0000000000d1d89b clang::Diagnostic::ProcessDiag() + 523
10 clang           0x0000000000d1da2d clang::DiagnosticBuilder::Emit() + 29
11 clang           0x00000000008ecd6d
clang::Sema::SemaDiagnosticBuilder::~SemaDiagnosticBuilder() + 173
12 clang           0x000000000094f2e8
clang::Sema::ParsedFreeStandingDeclSpec(clang::Scope*, clang::AccessSpecifier,
clang::DeclSpec&) + 408
13 clang           0x00000000008dca41
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier) + 1825
14 clang           0x00000000008df0d5
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 693
15 clang           0x00000000008bc619
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&, clang::CXX0XAttributeList) + 409
16 clang           0x00000000008b2a53
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList,
clang::Parser::ParsingDeclSpec*) + 1091
17 clang           0x00000000008b2c92
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 114
18 clang           0x000000000089afcb clang::ParseAST(clang::Sema&, bool) + 139
19 clang           0x000000000076da24 clang::CodeGenAction::ExecuteAction() +
68
20 clang           0x0000000000667b95
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
21 clang           0x00000000006476dc
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
22 clang           0x000000000063f595 cc1_main(char const**, char const**, char
const*, void*) + 629
23 clang           0x0000000000646697 main + 4087
24 libc.so.6       0x00007fbaf18a2c4d __libc_start_main + 253
25 clang           0x000000000063dce9
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
t.bashed.902.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -resource-dir /usr/local/bin/../lib/clang/2.9 -ferror-limit 19
-fmessage-length 0 -fexceptions -fgnu-runtime -fdiagnostics-show-option -o
t.bashed.902.o -x c++ t.bashed.902.cc 
1.      <eof> parser at end of file
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Mon Nov 22 05:09:09 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 05:09:09 -0600 (CST)
Subject: [LLVMbugs] [Bug 8663] New: Assertion 'Lookup of member name should
 be either overloaded, single or null' on invalid code
Message-ID: <bug-8663-206@http.llvm.org/bugs/>

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

           Summary: Assertion 'Lookup of member name should be either
                    overloaded, single or null' on invalid code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The single line:

struct{__new_finish;__new_finish(;__new_finish;

Produces the following assertion when compiled with clang++:

t.bashed.8907.cc:1:8: error: C++ requires a type specifier for all declarations
struct{__new_finish;__new_finish(;__new_finish;
       ^~~~~~~~~~~~
t.bashed.8907.cc:1:34: error: expected parameter declarator                     
struct{__new_finish;__new_finish(;__new_finish;
                                 ^
t.bashed.8907.cc:1:34: error: expected ')'                                      
t.bashed.8907.cc:1:33: note: to match this '('
struct{__new_finish;__new_finish(;__new_finish;
                                ^
t.bashed.8907.cc:1:21: error: C++ requires a type specifier for all
declarations                                                                    
struct{__new_finish;__new_finish(;__new_finish;
                    ^~~~~~~~~~~~
t.bashed.8907.cc:1:35: error: C++ requires a type specifier for all
declarations                                                                    
struct{__new_finish;__new_finish(;__new_finish;
                                  ^~~~~~~~~~~~
clang: SemaDecl.cpp:6315: clang::FieldDecl*
clang::Sema::HandleField(clang::Scope*, clang::RecordDecl*,
clang::SourceLocation, clang::Declarator&, clang::Expr*,
clang::AccessSpecifier): Assertion `(Previous.empty() ||
Previous.isOverloadedResult() || Previous.isSingleResult()) && "Lookup of
member name should be either overloaded, single or null"' failed.
0  clang           0x00000000016a2fcf
1  clang           0x00000000016a5242
2  libpthread.so.0 0x00007f25c7c9d8f0
3  libc.so.6       0x00007f25c6f8ca75 gsignal + 53
4  libc.so.6       0x00007f25c6f905c0 abort + 384
5  libc.so.6       0x00007f25c6f85941 __assert_fail + 241
6  clang           0x000000000095d58c clang::Sema::HandleField(clang::Scope*,
clang::RecordDecl*, clang::SourceLocation, clang::Declarator&, clang::Expr*,
clang::AccessSpecifier) + 1180
7  clang           0x000000000097a931
clang::Sema::ActOnCXXMemberDeclarator(clang::Scope*, clang::AccessSpecifier,
clang::Declarator&, clang::ASTMultiPtr<clang::TemplateParameterList*>,
clang::Expr*, clang::Expr*, bool, bool) + 561
8  clang           0x00000000008c5ae1
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 2641
9  clang           0x00000000008c7f4f
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 1583
10 clang           0x00000000008c8e30
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 2848
11 clang           0x00000000008b9484
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 2004
12 clang           0x00000000008b08d6
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AttributeList*, clang::AccessSpecifier) + 150
13 clang           0x00000000008b0d24
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AttributeList*,
clang::AccessSpecifier) + 372
14 clang           0x00000000008b2b45
clang::Parser::ParseExternalDeclaration(clang::CXX0XAttributeList,
clang::Parser::ParsingDeclSpec*) + 1333
15 clang           0x00000000008b2c92
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 114
16 clang           0x000000000089afcb clang::ParseAST(clang::Sema&, bool) + 139
17 clang           0x000000000076da24 clang::CodeGenAction::ExecuteAction() +
68
18 clang           0x0000000000667b95
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
19 clang           0x00000000006476dc
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1276
20 clang           0x000000000063f595 cc1_main(char const**, char const**, char
const*, void*) + 629
21 clang           0x0000000000646697 main + 4087
22 libc.so.6       0x00007f25c6f77c4d __libc_start_main + 253
23 clang           0x000000000063dce9
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
t.bashed.8907.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -resource-dir /usr/local/bin/../lib/clang/2.9 -ferror-limit 19
-fmessage-length 208 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o t.bashed.8907.o -x c++ t.bashed.8907.cc 
1.      t.bashed.8907.cc:1:47: current parser token ';'
2.      t.bashed.8907.cc:1:1: parsing struct/union/class body
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Mon Nov 22 11:52:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 11:52:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 8419] 'clang --analyze' crashes when ref value
 returned by operator[] is '&='ed
In-Reply-To: <bug-8419-206@http.llvm.org/bugs/>
References: <bug-8419-206@http.llvm.org/bugs/>
Message-ID: <20101122175207.5197A2A6C12C@llvm.org>

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

Zhanyong Wan <zhanyong.wan at gmail.com> changed:

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

--- Comment #5 from Zhanyong Wan <zhanyong.wan at gmail.com> 2010-11-22 11:52:06 CST ---
Fixed in r119960.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 12:39:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 12:39:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 8664] New: code size regression over time
Message-ID: <bug-8664-206@http.llvm.org/bugs/>

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

           Summary: code size regression over time
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


I've been doing some code-size testing over time (quite frequently in 2009 and
much less frequenly in 2010) and it looks like code size of llvm compiled
(using clang) code is regressing (tested on gnu screen)


see:   http://lev.vlakno.cz/~rdivacky/clang.sizes.txt

I propose to

1) start checking code size of some given test base (gnu screen worked ok for
me), having data available to check for regressions

2) investigate some bigger jumps in the data provided (you can skip the start
of the list - that was produced back when ccc (the old driver) ignored -O2)

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

From bugzilla-daemon at llvm.org  Mon Nov 22 17:03:41 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 17:03:41 -0600 (CST)
Subject: [LLVMbugs] [Bug 8665] New: intel assembly syntax parser for mc
Message-ID: <bug-8665-206@http.llvm.org/bugs/>

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

           Summary: intel assembly syntax parser for mc
           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: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


Binutils lets you switch between Intel and AT&T syntax assembly in the middle
of a program, using ".intex_syntax noprefix" and ".att_syntax". Even worse, it
turns out that this is a popular thing to do:

  http://google.com/codesearch?as_q=\.intel_syntax

I don't think we have an intel syntax parser yet, in which case supporting this
will require writing one.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 17:05:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 17:05:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 8666] New: [patch] improvement of -show-annotations
	option
Message-ID: <bug-8666-206@http.llvm.org/bugs/>

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

           Summary: [patch] improvement of -show-annotations option
           Product: tools
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-dis
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jerrry94087 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


This patch adds value type to value annotation

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

From bugzilla-daemon at llvm.org  Mon Nov 22 19:45:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 19:45:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8601] poor location information for 'invalid const'
	diagnostic
In-Reply-To: <bug-8601-206@http.llvm.org/bugs/>
References: <bug-8601-206@http.llvm.org/bugs/>
Message-ID: <20101123014535.B2CA92A6C12E@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2010-11-22 19:45:35 CST ---


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

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

From bugzilla-daemon at llvm.org  Mon Nov 22 20:16:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 20:16:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8660] C API is lacking useful features available in
	the C++ API
In-Reply-To: <bug-8660-206@http.llvm.org/bugs/>
References: <bug-8660-206@http.llvm.org/bugs/>
Message-ID: <20101123021646.F2E132A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-22 20:16:46 CST ---
We do not aim for the C api to support everything, we add things on an
as-needed basis.  Please send patches to the llvm-commits mailing list.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 20:19:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 20:19:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 8667] New: linking errors on FreeBSD-i386 with
	clang trunk
Message-ID: <bug-8667-206@http.llvm.org/bugs/>

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

           Summary: linking errors on FreeBSD-i386 with clang trunk
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chromium at hybridsource.org
                CC: llvmbugs at cs.uiuc.edu


I'm compiling Chromium on FreeBSD i386 and have had linking errors for the last
3 weeks when using clang trunk, though the same source links fine if I use
clang 2.8 on i386 or clang trunk on amd64.  The problem started when I updated
to llvm-117848/clang-117842 and persists up to clang 119910 today.  These are
the two linker errors that I keep hitting now with the system GNU linker:

/usr/bin/ld:
out/Release/obj.host/ssl_false_start_blacklist_process/net/base/ssl_false_start_blacklist_process.o(.text.main+0x886):
unresolvable relocation against symbol
`_ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4'

/usr/bin/ld:
out/Release/obj.host/protoc/third_party/protobuf/src/google/protobuf/compiler/code_generator.o(.text._ZN6google8protobuf8compiler23ParseGeneratorParameterERKSsPSt6vectorISt4pairISsSsESaIS6_EE+0xd1):
unresolvable relocation against symbol
`_ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4'

Rafael asked me if integrated-as made a difference so I just tried it and it
made no difference if it was turned on or off: I usually compile with
integrated-as turned off.  I took a look at that symbol in the object files and
nothing stood out for me, between the objects generated by clang 2.8 and trunk.
 rjmccall asked for the command line and preprocessed source so I'm attaching
those.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 21:41:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 21:41:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 8668] New: Use of multiple using declaration in a
 function scope (Another erroneous compilation)
Message-ID: <bug-8668-206@http.llvm.org/bugs/>

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

           Summary: Use of multiple using declaration in a function scope
                    (Another erroneous compilation)
           Product: clang
           Version: 2.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: prasoonsaurav.nit at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


ISO C++ 7.3.3/8 says - "A using-declaration is a declaration and can therefore
be used repeatedly where (and only where) multiple declarations are allowed."

So

namespace A{
   int i;
}

int main(){
   using A::i;
   using A::i;
}

is ill-formed according to the Standard. But Clang erroneously compiles the
above code snippet.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 22:12:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 22:12:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 8669] New: friend decls get put in the wrong
 DeclContext in certain situations
Message-ID: <bug-8669-206@http.llvm.org/bugs/>

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

           Summary: friend decls get put in the wrong DeclContext in
                    certain situations
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: csilvers2000 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Consider the following code:
---
1 struct B {
2   template<class T> class C;
3   template<class T> friend class C;
4   //friend class C<float>;
5 };
6
7 template<class T> class C { };
8
9 C<int>* foo;
---
The declaration at line 7 and the declarations and line 2 and 3 are put in
separate DeclContexts (as far as I can tell).  To see this, when looking at the
CXXRecord for C<int> on line 9, and looking at the redecls (via
redecl_begin()/end()), the only redecl it shows is for line 7.

However, if I uncomment line 4, the situation changes.  Now if I look at the
redecls for C<float> on line 4, I see line 2, line 3, and line 7.  All 3 of
these have the same DeclContext (that is, record_decl->getParent() produces the
same output in each case), which is the DeclContext for this translation unit.

Likewise, if I look at the redecls for C<int> on line 9, I see all three decls,
on lines 2, 3, and 7.  They still all have the same DeclContext. :-)

I would not expect uncommenting line 4 to change whether lines 2 and 3 are
redecls of line 7 or not.  Nor would I expect, in any case, that the decls on
line 2 and 3 should be in the global (translation-unit) DeclContext, rather
than a DeclContext for class B.

It seems to me that the behavior when line 4 is commented is correct, but the
behavior when it is uncommented is incorrect, and clang is conflating two
DeclContexts that it shouldn't be.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 22:30:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 22:30:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 8670] New: Optimization causes incorrect output.
Message-ID: <bug-8670-206@http.llvm.org/bugs/>

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

           Summary: Optimization causes incorrect output.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joelteichroeb at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5821)
 --> (http://llvm.org/bugs/attachment.cgi?id=5821)
The bug in action.

If the code attached is compiled without optimization it outputs 6 as it
should. But if -O is used the output is wrong.

[joel at joel-pc list]$ clang list.c -o list
[joel at joel-pc list]$ ./list
6
[joel at joel-pc list]$ clang -O list.c -o list
[joel at joel-pc list]$ ./list
16474128
[joel at joel-pc list]$ 

The code in list.c is derived from wayland's(http://wayland.freedesktop.org/)
linked list code.

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

From bugzilla-daemon at llvm.org  Mon Nov 22 23:19:20 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 22 Nov 2010 23:19:20 -0600 (CST)
Subject: [LLVMbugs] [Bug 8670] Optimization causes incorrect output.
In-Reply-To: <bug-8670-206@http.llvm.org/bugs/>
References: <bug-8670-206@http.llvm.org/bugs/>
Message-ID: <20101123051920.94ECD2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-22 23:19:20 CST ---
It's not obvious, but this is because your program has undefined behavior. 
This line:


    struct IntContainer *a =
          (void *)((char *)(list->next) -
                   ((char *)&a->link - (char *)(a)));

contains a dereference of a->link before a is set.  Since a contains an
uninitialized variable, a->link and a are not guaranteed to have related
values.

This is more complex but equivalent to:

int a;
print(a-a)

which is not guaranteed to print zero.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 07:57:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 07:57:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 8671] New: Incorrect code generation using opt for
	arch x86
Message-ID: <bug-8671-206@http.llvm.org/bugs/>

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

           Summary: Incorrect code generation using opt for arch x86
           Product: tools
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: babslachem at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Use attached dumbret.ll file and generate dumbret as follows:

llc -march=x86 -O2 dumbret.ll -o dumbret.s
gcc -m32 dumbret.s -o dumbret

launch dumbret exec:
./dumbret

You should get following output:
114 15 7345

Now use opt on this file as follows:

opt dumbret.ll -disable-inlining -realign-stack -O2 -S -o dumbret.oll
llc -march=x86 -O2 dumbret.oll -o odumbret.s

gcc -m32 odumbret.s -o odumbret

launch odumbret exec:
./odumbret

You should get a SEGFAULT.

Now look at generated code for odumbret before call to retzerosec:

...
    movsd    24, %xmm0
    movsd    %xmm0, 28(%esp)
    movsd    16, %xmm0
    movsd    %xmm0, 20(%esp)
    movsd    0, %xmm0
    movsd    8, %xmm1
    movsd    %xmm1, 12(%esp)
    movsd    %xmm0, 4(%esp)
    leal    40(%esp), %ecx
    movl    %ecx, (%esp)
    call    retzerosec
...

I guess what should be generated is something like:

    movsd    $24, %xmm0

instead of 

    movsd    24, %xmm0

Moreover, instruction movsd $24, %xmm0 doesn't exists.
So something different should be generated to move value 24 into xmm0 reg,
instead of trying to move what's at address 24 into xmm0.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 07:59:04 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 07:59:04 -0600 (CST)
Subject: [LLVMbugs] [Bug 6829] MS extension for nameless struct members
	missing
In-Reply-To: <bug-6829-206@http.llvm.org/bugs/>
References: <bug-6829-206@http.llvm.org/bugs/>
Message-ID: <20101123135904.98AC42A6C12D@llvm.org>

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

Francois Pichet <pichet2000 at gmail.com> changed:

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

--- Comment #4 from Francois Pichet <pichet2000 at gmail.com> 2010-11-23 07:59:04 CST ---
Implemented in r120000.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 10:02:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 10:02:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 8671] Incorrect code generation using opt for arch
	x86
In-Reply-To: <bug-8671-206@http.llvm.org/bugs/>
References: <bug-8671-206@http.llvm.org/bugs/>
Message-ID: <20101123160244.706232A6C12C@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2010-11-23 10:02:44 CST ---
The function @retzerosec takes two arguments, as seen here:

define void @retzerosec(%struct.U1* noalias sret %agg.result, %struct.U1* byval
align 4 %ux) nounwind {

But when you call it you only pass one argument, as seen here:

  call void (%struct.U1*, ...)* bitcast (void (%struct.U1*, %struct.U1*)*
@retzerosec to void (%struct.U1*, ...)*)(%struct.U1* noalias sret %temp)
nounwind

This results in undefined behaviour such as you are seeing.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 10:44:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 10:44:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 8672] New: emitting SFENCE memory barrier for JIT
 fails with assertion / unreachable
Message-ID: <bug-8672-206@http.llvm.org/bugs/>

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

           Summary: emitting SFENCE memory barrier for JIT fails with
                    assertion / unreachable
           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: hammacher at cs.uni-saarland.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5823)
 --> (http://llvm.org/bugs/attachment.cgi?id=5823)
bitcode file causing lli to crash

I found that lli is unable to execute a memory barrier which only requires an
SFENCE instruction in x86. I can reproduce the behavior in TOT (r120026).

Simple bitcode file (bc file attached):
    define internal i32 @main() {
    entry:
      call void @llvm.memory.barrier(i1 false, i1 false, i1 false, i1 true, i1
true)
      ret i32 47
    }

    declare void @llvm.memory.barrier(i1, i1, i1, i1, i1) nounwind

The error disappears if any of the first three arguments to llvm.memory.barrier
is changed to true, because then an MFENCE is generated instead of SFENCE
(checked by adding --debug-only=x86-emitter).
Setting only the first and the last parameter produces an LFENCE which
surprisingly does also work!

Trying to run the "program" with lli version 2.7 fails with this assertion:
Assertion failed: (i < getNumOperands() && "getOperand() out of range!"),
function getOperand, file
/usr/src/llvm-2.7/include/llvm/CodeGen/MachineInstr.h, line 159.

Stacktrace:
    #0  0x00007fff85fd5616 in __kill ()
    #1  0x00007fff86075cca in abort ()
    #2  0x00007fff86062c90 in __assert_rtn ()
    #3  0x000000010013549f in llvm::MachineInstr::getOperand (this=0x103836a20,
i=0) at MachineInstr.h:159
    #4  0x0000000100133bb2 in emitInstruction (this=0x10311c310,
MI=@0x103836a20, Desc=0x10028f6f8) at X86CodeEmitter.cpp:765
    #5  0x0000000100132760 in runOnMachineFunction (this=0x10311c310,
MF=@0x10311d550) at X86CodeEmitter.cpp:136
    #6  0x0000000100d77faf in llvm::MachineFunctionPass::runOnFunction
(this=0x10311c310, F=@0x103107cf0) at MachineFunctionPass.cpp:27
    #7  0x000000010271de13 in llvm::FPPassManager::runOnFunction
(this=0x10310a190, F=@0x103107cf0) at PassManager.cpp:1350
    #8  0x000000010271daeb in llvm::FunctionPassManagerImpl::run
(this=0x103109c20, F=@0x103107cf0) at PassManager.cpp:1301
    #9  0x000000010271d791 in llvm::FunctionPassManager::run (this=0x103109210,
F=@0x103107cf0) at PassManager.cpp:1231
    #10 0x0000000100b1e3d2 in llvm::JIT::runJITOnFunctionUnlocked
(this=0x103109b20, F=0x103107cf0, locked=@0x7fff5fbfef80) at JIT.cpp:631
    #11 0x0000000100b1e7a3 in llvm::JIT::getPointerToFunction
(this=0x103109b20, F=0x103107cf0) at JIT.cpp:683
    #12 0x0000000100b1d09b in llvm::JIT::runFunction (this=0x103109b20,
F=0x103107cf0, ArgValues=@0x7fff5fbff440) at JIT.cpp:401
    #13 0x0000000100c4a0f1 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x103109b20, Fn=0x103107cf0, argv=@0x10000f138, envp=0x7fff5fbff788) at
ExecutionEngine.cpp:372
    #14 0x0000000100003c7c in main (argc=3, argv=0x7fff5fbff768,
envp=0x7fff5fbff788) at lli.cpp:234

lli version:
    Low Level Virtual Machine (http://llvm.org/):
      llvm version 2.7
      DEBUG build with assertions.
      Built Nov 20 2010 (11:44:09).
      Host: x86_64-apple-darwin10
      Host CPU: penryn

      Registered Targets:
        x86    - 32-bit X86: Pentium-Pro and above
        x86-64 - 64-bit X86: EM64T and AMD64


lli from TOT (2.9svn) produces these errors:
    Unknown FormMask value in X86 MachineCodeEmitter!
    UNREACHABLE executed at X86CodeEmitter.cpp:712!

Stacktrace:
    #0  0x00007fff86062cae in __pthread_kill ()
    #1  0x00007fff860625d2 in pthread_kill ()
    #2  0x00000001000259ab in raise (sig=6) at Signals.inc:278
    #3  0x0000000100025a40 in abort () at Signals.inc:298
    #4  0x00000001007c0155 in llvm::llvm_unreachable_internal (msg=Could not
find the frame base for "llvm::llvm_unreachable_internal(char const*, char
const*, unsigned int)".
) at ErrorHandling.cpp:99
    #5  0x0000000100082294 in emitInstruction (this=0x10231b5b0,
MI=@0x102838e60, Desc=0x100c24680) at X86CodeEmitter.cpp:712
    #6  0x00000001000818bc in runOnMachineFunction (this=0x10231b5b0,
MF=@0x10231c300) at X86CodeEmitter.cpp:136
    #7  0x00000001003b6987 in llvm::MachineFunctionPass::runOnFunction
(this=0x10231b5b0, F=@0x102305c70) at MachineFunctionPass.cpp:33
    #8  0x0000000100756c55 in llvm::FPPassManager::runOnFunction
(this=0x1023054a0, F=@0x102305c70) at PassManager.cpp:1452
    #9  0x000000010075691d in llvm::FunctionPassManagerImpl::run
(this=0x102305160, F=@0x102305c70) at PassManager.cpp:1403
    #10 0x00000001007565c3 in llvm::FunctionPassManager::run (this=0x102304e40,
F=@0x102305c70) at PassManager.cpp:1333
    #11 0x0000000100315342 in llvm::JIT::jitTheFunction (this=0x102306eb0,
F=0x102305c70, locked=@0x7fff5fbfef60) at JIT.cpp:661
    #12 0x0000000100315209 in llvm::JIT::runJITOnFunctionUnlocked
(this=0x102306eb0, F=0x102305c70, locked=@0x7fff5fbfef60) at JIT.cpp:640
    #13 0x0000000100315617 in llvm::JIT::getPointerToFunction
(this=0x102306eb0, F=0x102305c70) at JIT.cpp:697
    #14 0x0000000100313eef in llvm::JIT::runFunction (this=0x102306eb0,
F=0x102305c70, ArgValues=@0x7fff5fbff460) at JIT.cpp:412
    #15 0x000000010060af3f in llvm::ExecutionEngine::runFunctionAsMain
(this=0x102306eb0, Fn=0x102305c70, argv=@0x100c51478, envp=0x7fff5fbff810) at
ExecutionEngine.cpp:403
    #16 0x000000010002685d in main (argc=3, argv=0x7fff5fbff7f0,
envp=0x7fff5fbff810) at lli.cpp:251


lli version:
    Low Level Virtual Machine (http://llvm.org/):
      llvm version 2.9svn
      DEBUG build with assertions.
      Built Nov 23 2010 (17:00:30).
      Host: x86_64-apple-darwin10
      Host CPU: penryn

      Registered Targets:
        x86    - 32-bit X86: Pentium-Pro and above
        x86-64 - 64-bit X86: EM64T and AMD64

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

From bugzilla-daemon at llvm.org  Tue Nov 23 12:29:00 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 12:29:00 -0600 (CST)
Subject: [LLVMbugs] [Bug 8673] New: poor error recovery on incorrect type
 name in method argument
Message-ID: <bug-8673-206@http.llvm.org/bugs/>

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

           Summary: poor error recovery on incorrect type name in method
                    argument
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This code:


class ABC;
class foo {
  void bar(ABC *X);
};
void foo::bar(DEF *X) {
}

produces:


t.cc:8:11: error: variable has incomplete type 'void'
void foo::bar(DEF *X) {
          ^
t.cc:8:15: error: use of undeclared identifier 'DEF'
void foo::bar(DEF *X) {
              ^
t.cc:8:20: error: use of undeclared identifier 'X'
void foo::bar(DEF *X) {
                   ^
t.cc:8:22: error: expected ';' after top level declarator
void foo::bar(DEF *X) {
                     ^
                     ;
4 errors generated.


because the parser gets to DEF (which it doesn't know, and decides that DEF
isn't or couldn't be a type, so it backtracks and parses the code as "void
foo;" which goes horribly wrong downstream.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 12:57:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 12:57:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 8674] New: bewildering error message: cannot
 initialize a parameter of type 'struct stat *' with an rvalue of type
 'struct stat *'
Message-ID: <bug-8674-206@http.llvm.org/bugs/>

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

           Summary: bewildering error message: cannot initialize a
                    parameter of type 'struct stat *' with an rvalue of
                    type 'struct stat *'
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I got this today (where 'baz' was 'stat', renamed to be a little less
confusing):

t.cc:14:16: error: cannot initialize a parameter of type 'struct stat *' with
an
      rvalue of type 'struct stat *'
  ::baz("foo", &X);
               ^~
t.cc:10:36: note: passing argument to parameter here
void baz(const char*, struct stat *);
                                   ^

This is incredibly confusing and took me a long time to figure out what was
going wrong.  Here's the reduced input:


namespace clang {
class foo {
  void bar(struct stat &X);
};
}

struct stat;
void baz(const char*, struct stat *);

using namespace clang;
void foo::bar(struct stat &X) {
  ::baz("foo", &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 Nov 23 16:04:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 16:04:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 8668] Use of multiple using declaration in a
 function scope (Another erroneous compilation)
In-Reply-To: <bug-8668-206@http.llvm.org/bugs/>
References: <bug-8668-206@http.llvm.org/bugs/>
Message-ID: <20101123220414.783932A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #1 from John McCall <rjmccall at apple.com> 2010-11-23 16:04:14 CST ---
Fixed in r120063.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 16:13:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 16:13:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 8675] New: protected member access check should
 only apply to functions or data members
Message-ID: <bug-8675-206@http.llvm.org/bugs/>

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

           Summary: protected member access check should only apply to
                    functions or data members
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


11.5 is such a great passage. It reads that "When a friend or a member function
of a derived class references a protected nonstatic member function or
protected nonstatic data member of a base class, an access check applies in
addition..."

Consider this testcase:

  class Base {
    protected:
    struct Foo { int i; };
  };

  struct Derived : public Base {
    friend class Friend;
  };

  struct Friend {
    void f() {
      Base::Foo foo = { 42 };
    }
  };

which is accepted by gcc but rejected by clang:

b3224358.cc:12:11: error: 'Foo' is a protected member of 'Base'
    Base::Foo foo = { 42 };
          ^
b3224358.cc:3:10: note: declared protected here
  struct Foo { int i; };
         ^
1 error generated.

In this case, the member is neither a nonstatic function nor a data member of a
base class, so the additional access specified in 11.5 should not apply.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 18:11:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 18:11:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 8676] New: Clang fails to selfhost on
 i386-darwin10: missing __eprintf symbol
Message-ID: <bug-8676-206@http.llvm.org/bugs/>

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

           Summary: Clang fails to selfhost on i386-darwin10: missing
                    __eprintf symbol
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


A simple i386-apple-darwin10 clang selfhost fails with a linker error:

http://google1.osuosl.org:8011/builders/clang-i386-darwin10-selfhost-rel/builds/15

Undefined symbols:
  "___eprintf", referenced from:
      ___eprintf$non_lazy_ptr in
libLLVMSystem.a(SearchForAddressOfSpecialSymbol.o)
     (maybe you meant: ___eprintf$non_lazy_ptr)
ld: symbol(s) not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Presumably, compiling clang with compiler-rt should fix this, but that requires
ARM bits to be installed, see PR8655.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 20:20:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 20:20:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 8659] tcmalloc in Chromium segfaults when compiled
 with both -fPIC and integrated-as
In-Reply-To: <bug-8659-206@http.llvm.org/bugs/>
References: <bug-8659-206@http.llvm.org/bugs/>
Message-ID: <20101124022049.5159A2A6C124@llvm.org>

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

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

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

--- Comment #10 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-23 20:20:48 CST ---
Probably fixed in 120076. Please reopen if not.

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

From bugzilla-daemon at llvm.org  Tue Nov 23 22:23:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 23 Nov 2010 22:23:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 8677] New: likely integer wrong code bug
Message-ID: <bug-8677-206@http.llvm.org/bugs/>

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

           Summary: likely integer wrong code bug
           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


The -O1 result is correct.

regehr at home:~/volatile/bugs/tmp342$ clang -O1 small.c -o small
regehr at home:~/volatile/bugs/tmp342$ ./small
1
regehr at home:~/volatile/bugs/tmp342$ clang -O2 small.c -o small
regehr at home:~/volatile/bugs/tmp342$ ./small
-1
regehr at home:~/volatile/bugs/tmp342$ cat small.c
int printf (const char *format, ...);

static int g_23 = 1;

static int func_16 (int p_19)
{
  g_23 = -1;
  return p_19;
}

int main (void) 
{
  int *l_172[1];
  int **l_176 = &l_172[0];
  int i;
  for (i = 0; i < 1; i++) {
    l_172[i] = &g_23;
  }
  **l_176 = func_16 (**l_176);
  printf ("%d\n", g_23);
  return 0;
}
regehr at home:~/volatile/bugs/tmp342$ clang -v
clang version 2.9 (trunk 120082)
Target: i386-pc-linux-gnu
Thread model: posix

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

From bugzilla-daemon at llvm.org  Wed Nov 24 04:44:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 04:44:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 8678] New: Destructors are not called for C++ temp
 objects that are created when C++ objects are copied via ObjC dot syntax
Message-ID: <bug-8678-206@http.llvm.org/bugs/>

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

           Summary: Destructors are not called for C++ temp objects that
                    are created when C++ objects are copied via ObjC dot
                    syntax
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: lgerbarg at gmail.com
                CC: llvmbugs at cs.uiuc.edu


While tracing down a a ref leak with C++ shared_ptrs I found a situation where
the shared_ptr's destructor was not being called, which was artificially
increasing the ref count of the object and preventing its deletion. Below is a
reduced case that demonstrates the problem and two workaround. The bug only
occurs using ObjC dot syntax, if you use the getter via bracket syntax
everything works as expected.

#include <Foundation/Foundation.h>

#include <tr1/memory>
#include <stdio.h>

class CXXClass {
private:
  unsigned long identity;
public:
  CXXClass(short I) : identity(I) {
    printf("Constructing: %lu\n", identity);
  }

  ~CXXClass(void) {
    printf("Destructing: %lu\n", identity);
  }

  unsigned long getIdentity(void) { return identity; }
};

@interface OBJCClass : NSObject {
  std::tr1::shared_ptr<CXXClass> cxxClass;
}

@property (nonatomic) std::tr1::shared_ptr<CXXClass> cxxClass;
@end

@implementation OBJCClass
@end

int main (void) {
  OBJCClass *test1 = [[OBJCClass alloc] init];
  OBJCClass *test2 = [[OBJCClass alloc] init];
  OBJCClass *test3 = [[OBJCClass alloc] init];
  OBJCClass *test4 = [[OBJCClass alloc] init];

  test1.cxxClass = std::tr1::shared_ptr<CXXClass>(new CXXClass(1));
  test2.cxxClass = std::tr1::shared_ptr<CXXClass>(new CXXClass(2));
  test3.cxxClass = std::tr1::shared_ptr<CXXClass>(new CXXClass(3));
  test4.cxxClass = std::tr1::shared_ptr<CXXClass>(new CXXClass(4));

  printf("Purposefully ignoring id 1 as a control group\n");

  //BUG
  //The property accessor copies cxxClass into a temp variable that is not
registered for cleanup
  //Therefore the shared_ptr destructor is never called, and we leak the
CXXClass pointed to by
  //test2.cxxClass
  printf("Reading id %lu\n", test2.cxxClass->getIdentity());

  //Workaround 1
  //If you use normal ObjC message syntax instead of dot accessors everything
works correctly
  printf("Reading id %lu\n", [test3 cxxClass]->getIdentity());

  //Workaround 2
  //If we explicitly assign the object to a name it will work fine
  std::tr1::shared_ptr<CXXClass> temp = test4.cxxClass;
  printf("Reading id %lu\n", temp->getIdentity());

  //Control group, destructor called
  [test1 release];

  //Bugged version, destructor not called
  [test2 release];

  //Workaround 1 (destructor called later, at scope collapse);
  [test3 release];

  //Workaround 2 (destructor called later, at scope collapse);
  [test4 release];

  return 0;
}

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

From bugzilla-daemon at llvm.org  Wed Nov 24 09:05:12 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 09:05:12 -0600 (CST)
Subject: [LLVMbugs] [Bug 8679] New: -O1 compilation uses all memory and
 fails on 32- and 64-bit Ubuntu 10.10 installs
Message-ID: <bug-8679-206@http.llvm.org/bugs/>

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

           Summary: -O1 compilation uses all memory and fails on 32- and
                    64-bit Ubuntu 10.10 installs
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bugzilla at lklundin.dk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5825)
 --> (http://llvm.org/bugs/attachment.cgi?id=5825)
GPLed C99 code after clang -E, fails with -O1

clang -c -o /dev/null naco_img_jitter_cpp.c

succeeds in about 0.3s. However,

clang -c -o /dev/null naco_img_jitter_cpp.c -O1

will run and allocate memory via brk() and later also mmap()
until mmap() returns ENOMEM and the compilation fails.

The problem also occurs with -O2.

The system runs 64-bit Ubuntu 10.10 with

$ clang --version
clang version 2.8 (branches/release_28)
Target: x86_64-pc-linux-gnu
Thread model: posix

The problem is also present on a 32-bit Ubuntu 10.10 with

$ clang --version
clang version 2.8 (branches/release_28)
Target: i386-pc-linux-gnu
Thread model: posix

The attached source code example has been generated with clang -E from GPL C99
source code that compiles and runs as expected with various versions of 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  Wed Nov 24 09:15:49 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 09:15:49 -0600 (CST)
Subject: [LLVMbugs] [Bug 8680] New: scalarrepl crash on alloca that is
 bitcast to a function pointer and then called
Message-ID: <bug-8680-206@http.llvm.org/bugs/>

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

           Summary: scalarrepl crash on alloca that is bitcast to a
                    function pointer and then called
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Run "opt -scalarrepl" on the following to enjoy the crash:

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"

define void @main() nounwind {
entry:
  %memtmp = alloca i32, align 4
  %0 = bitcast i32* %memtmp to void ()*
  call void %0() nounwind
  ret void
}

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

From bugzilla-daemon at llvm.org  Wed Nov 24 11:21:57 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 11:21:57 -0600 (CST)
Subject: [LLVMbugs] [Bug 8681] New: clang ToT can't parse boost::addressof
	any more
Message-ID: <bug-8681-206@http.llvm.org/bugs/>

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

           Summary: clang ToT can't parse boost::addressof any more
           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


This code (simplified from boost::addressof) stopped compiling with clang ToT
in the past day or so:

template<typename T> void a(T c) {
const_cast<char&>(reinterpret_cast<char&>(c)); }


It fails as follows:

$ clang++ clang-addressof.cpp
clang: <...>/clang-svn/lib/AST/ExprClassification.cpp:69: Cl
clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const:
Assertion `getValueKind() == VK_LValue' failed.
0  libLLVM-2.9svn.so 0xf7822c48
Stack dump:
0.      Program arguments: <...>/llvm-svn-build/Release+Asserts/bin/clang -cc1
-triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
clang-addressof.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.17.50.0.6
-resource-dir <...>/llvm-svn-build/Release+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 239 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-m3JX8A.o -x c++
clang-addressof.cpp 
1.      clang-addressof.cpp:1:81: current parser token ';'
2.      clang-addressof.cpp:1:34: parsing function body 'a'
3.      clang-addressof.cpp:1:34: in compound statement ('{}')
clang: error: unable to execute command: Aborted
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  Wed Nov 24 12:47:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 12:47:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 8682] New: clang should not issue
 -Wtautological-compare warnings on dependent values
Message-ID: <bug-8682-206@http.llvm.org/bugs/>

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

           Summary: clang should not issue -Wtautological-compare warnings
                    on dependent values
           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


$ cat taut.cpp 
template<unsigned n> bool compare(unsigned k) { return k >= n; }
int main() { return compare<0>(42); }
$ clang++ taut.cpp 
taut.cpp:1:58: warning: comparison of unsigned expression >= 0 is always true
[-Wtautological-compare]
template<unsigned n> bool compare(unsigned k) { return k >= n; }
                                                       ~ ^  ~
taut.cpp:2:21: note: in instantiation of function template specialization
'compare<0>' requested here
int main() { return compare<0>(42); }
                    ^
1 warning generated.


-Wtautological-compare should not be issued if the constant expression is
dependent on a template parameter. Equivalently, it should not be issued while
instantiating a template -- any correct warnings will have been generated while
parsing the template.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 12:50:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 12:50:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 8659] tcmalloc in Chromium segfaults when compiled
 with both -fPIC and integrated-as
In-Reply-To: <bug-8659-206@http.llvm.org/bugs/>
References: <bug-8659-206@http.llvm.org/bugs/>
Message-ID: <20101124185053.748AB2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8659

chromium at hybridsource.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #11 from chromium at hybridsource.org 2010-11-24 12:50:52 CST ---
Still segfaults when compiled with clang trunk 120098.  As before, problem goes
away if I remove -fPIC for the tcmalloc component alone.  Let me know if I can
provide any other info.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 13:43:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 13:43:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 8683] New: clang crash on parenthesized
 initialization of type with nontrivial copy ctor and copy assignment
Message-ID: <bug-8683-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8683

           Summary: clang crash on parenthesized initialization of type
                    with nontrivial copy ctor and copy assignment
           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


(vb is a very simplified version of std::vector<bool> from libstdc++)

$ cat tmp.cpp 
struct bvb {
  bvb();
  bvb(const bvb &);
};
struct vb : bvb {
  vb &operator=(const vb &__x);
};
struct foo {
  vb b;
};
void go() {
  vb tmp = (foo().b);
}
$ clang++ tmp.cpp
clang: <...>/clang-svn/lib/CodeGen/CGExprAgg.cpp:674: 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.
0  libLLVM-2.9svn.so 0xf77d4c48
Stack dump:
0.      Program arguments: <...>/llvm-svn-build/Release+Asserts/bin/clang -cc1
-triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
tmp.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.17.50.0.6
-resource-dir <...>/llvm-svn-build/Release+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 239 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Y359oY.o -x c++
tmp.cpp 
1.      <eof> parser at end of file
2.      tmp.cpp:11:6: LLVM IR generation of declaration 'go'
3.      tmp.cpp:11:6: Generating code for declaration 'go'
4.      tmp.cpp:11:11: LLVM IR generation of compound statement ('{}')


Removing the parens around foo().b makes this work. Using a vb instance
directly rather than a field of a function return value makes this work. Adding
a copy ctor to vb makes this work.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 14:48:51 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 14:48:51 -0600 (CST)
Subject: [LLVMbugs] [Bug 8684] New: [MC assembler] .code16 not supported
Message-ID: <bug-8684-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8684

           Summary: [MC assembler] .code16 not supported
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu


In FreeBSD, we have a few scattered pieces of 16-bit x86 assembly in the
tree, since these run in real mode; this mostly concerns boot loader
parts, but there is also at least one ACPI-related chunk (wakeup code).

Most of these are delineated with .code16 directives, but I see at least
one file that just consists of 'pure' 16-bit code.  This causes the
integrated assembler to choke with e.g.:

sio.s:46:17: error: invalid operand for instruction
sio_putc.1: inb (%dx),%al # Transmitter
                ^
sio.s:48:3: error: invalid instruction mnemonic 'loopz'
  loopz sio_putc.1 # No
  ^
sio.s:60:7: error: invalid operand for instruction
  inb (%dx),%al # Read character
      ^
sio.s:67:7: error: invalid operand for instruction
  inb (%dx),%al # Received data
      ^

This issue might also be shoved into bug 8595, but I guess 16 bit is
code is a rather different can of worms...  Though it is still necessary
in 2010, apparently. :)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 15:16:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 15:16:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 8685] New: [MC assembler] does not support square
 bracket notation
Message-ID: <bug-8685-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8685

           Summary: [MC assembler] does not support square bracket
                    notation
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu


The MC assembler does not appear to support the following notation,
using square brackets, which occurs in some x86 assembly files:

.size   x, [.-x]

Another example of this is used in FreeBSD, in combination with local
labels:

#define PIC_PROLOGUE    \
    pushl    %ebx;    \
    call    1f;    \
1:            \
    popl    %ebx;    \
    addl    $_GLOBAL_OFFSET_TABLE_+[.-1b],%ebx

As there is no reference at all in the gas documentation about this
'feature', I just looked in the source code instead...

It seems that only in case of ia64, square brackets are considered an
index operator (with unclear semantics, though).  For most other cases,
they are equivalent with parentheses.

In binutils trunk, there is also an exception for i386, but only if gas
is using Intel syntax at that particular point in the file.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 16:04:43 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 16:04:43 -0600 (CST)
Subject: [LLVMbugs] [Bug 8680] scalarrepl crash on alloca that is bitcast to
 a function pointer and then called
In-Reply-To: <bug-8680-206@http.llvm.org/bugs/>
References: <bug-8680-206@http.llvm.org/bugs/>
Message-ID: <20101124220443.7223E2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8680

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2010-11-24 16:04:43 CST ---
Fixed in r120126,
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20101122/112449.html

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 16:16:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 16:16:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 8686] New: [MC assembler] 'b' suffix on 'setxx'
 mnemonics not accepted
Message-ID: <bug-8686-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8686

           Summary: [MC assembler] 'b' suffix on 'setxx' mnemonics not
                    accepted
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu


In some contributed math library code in FreeBSD, there is the following
assembly instruction:

    setneb    %al

The 'b' suffix is not accepted by the MC assembler.  I know it is quite
redundant, but gas is the standard, unfortunately. :)

In binutils's i386 opcode table file, there is this fragment:

setne, 1, 0xf95, 0x0, 2, Cpu386,
Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, {
Reg8|Byte|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S }

E.g. it accepts the 'b' suffix, but not the w, l, s, q, ld suffixes.
The same holds for all the following mnemonics:

seta
setae
setb
setbe
setc
sete
setg
setge
setl
setle
setna
setnae
setnb
setnbe
setnc
setne
setng
setnge
setnl
setnle
setno
setnp
setns
setnz
seto
setp
setpe
setpo
sets
setz

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 16:54:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 16:54:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 8687] New: [MC assembler] default suffix of fld
	mnemonic?
Message-ID: <bug-8687-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8687

           Summary: [MC assembler] default suffix of fld mnemonic?
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu


In the FreeBSD tree, there exists this fragment of inline assembly in a
.c file:

        float x;
    ...
        __asm __volatile("ffree %%st(7); fld %0" : : "m" (x));

This gets compiled to the following preprocessed assembly:

    ffree    %st(7)
    fld    -4(%ebp)

Though the fld mnemonic misses a size suffix such as 's', gas assembles
it anyway, and apparently interprets it as a float operation:

   6:   dd c7                   ffree  %st(7)
   8:   d9 45 fc                flds   0xfffffffc(%ebp)

I'm not sure what the right approach is here; it seems rather arbitrary
to use flds by default, but apparently that's what gas does.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 16:58:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 16:58:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 8688] New: Copying block that captures itself in
 its declaration leads to garbage
Message-ID: <bug-8688-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8688

           Summary: Copying block that captures itself in its declaration
                    leads to garbage
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kevin at sb.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5827)
 --> (http://llvm.org/bugs/attachment.cgi?id=5827)
Test case

Calling Block_copy() during the declaration of a block variable that captures
itself results in a garbage value. The following snippet is all that's
necessary to reproduce:

    __block void (^broken)() = Block_copy(^{ (void)broken; });

I've attached a complete file that reproduces this issue when run.

This was reproduced in both Apple clang version 1.6 (tags/Apple/clang-70) and
Apple clang version 2.0 (tags/Apple/clang-121.4) (based on LLVM 2.9svn), in
both x86_64 and i386.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 17:37:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 17:37:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8689] New: false positive due to not analyzing
 value dependencies
Message-ID: <bug-8689-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8689

           Summary: false positive due to not analyzing value dependencies
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: korgulec at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Static analyzer for the attached file reports that:

/tmp/test.c:17:28: warning: Access to field 'a' results in a dereference of a
null pointer (loaded from variable 'X')
  return error ? NULL : X->a;
                        ~  ^

But clearly when X is dereferenced it cannot be 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  Wed Nov 24 17:50:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 17:50:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 8690] New: Block that inherits 'self' from
 enclosing block can get wrong value (ARM)
Message-ID: <bug-8690-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8690

           Summary: Block that inherits 'self' from enclosing block can
                    get wrong value (ARM)
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kevin at sb.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5828)
 --> (http://llvm.org/bugs/attachment.cgi?id=5828)
Testcase

In an obj-c method, when a block creates and calls a nested block, and the
nested block inherits 'self' from its parent, the value of 'self' in the nested
block may be different than the value in the enclosing block. So far this is
only reproducible when compiling for the iPad (e.g. ARM), and unrelated changes
to the surrounding code can cause this bug to appear and disappear. I've
attached a reduced testcase - it's an Xcode project, as it requires installing
onto an iPad to reproduce. ViewController.m contains the relevant source.

This was compiled using Apple clang version 1.6 (tags/Apple/clang-70) and run
on an iPad running iOS 4.2.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 Nov 24 18:36:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 18:36:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 8640] template diagnostic does not show point of
	error
In-Reply-To: <bug-8640-206@http.llvm.org/bugs/>
References: <bug-8640-206@http.llvm.org/bugs/>
Message-ID: <20101125003647.7ADC32A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8640

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Nick Lewycky <nlewycky at google.com> 2010-11-24 18:36:46 CST ---
Fixed in r120134,
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20101122/036756.html.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 19:46:24 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 19:46:24 -0600 (CST)
Subject: [LLVMbugs] [Bug 8691] New: clang fails to compile big static arrays
Message-ID: <bug-8691-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8691

           Summary: clang fails to compile big static arrays
           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: zl29ah at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I had around 700mb of free ram, so it seems pretty strange to me:

l29ah at l29ah-home /tmp $ echo 'char foo[12345678] = {1}; int main(){return
foo[1233];}' > a.c
l29ah at l29ah-home /tmp $ clang a.c
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
0  clang           0x00000000015f8dbf
1  clang           0x00000000015f9379
2  libpthread.so.0 0x00007f8a5c495470
3  libc.so.6       0x00007f8a5b7a87c5 gsignal + 53
4  libc.so.6       0x00007f8a5b7a9c46 abort + 390
5  libstdc++.so.6  0x00007f8a5c0376ad __gnu_cxx::__verbose_terminate_handler()
+ 285
6  libstdc++.so.6  0x00007f8a5c035976
7  libstdc++.so.6  0x00007f8a5c0359a3
8  libstdc++.so.6  0x00007f8a5c035aae
9  libstdc++.so.6  0x00007f8a5c035e9d operator new(unsigned long) + 125
10 clang           0x0000000001553bda llvm::User::operator new(unsigned long,
unsigned int) + 42
11 clang           0x00000000014d6934
llvm::ConstantUniqueMap<std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> >, llvm::ArrayType, llvm::ConstantArray,
true>::Create(llvm::ArrayType const*, std::vector<llvm::Constant*,
std::allocator<llvm::Constant*> > const&,
std::_Rb_tree_iterator<std::pair<std::pair<llvm::ArrayType const*,
std::vector<llvm::Constant*, std::allocator<llvm::Constant*> > > const,
llvm::ConstantArray*> >) + 52
12 clang           0x00000000014c901e llvm::ConstantArray::get(llvm::ArrayType
const*, std::vector<llvm::Constant*, std::allocator<llvm::Constant*> > const&)
+ 622
13 clang           0x0000000000810938
14 clang           0x0000000000810a99
clang::CodeGen::CodeGenModule::EmitConstantExpr(clang::Expr const*,
clang::QualType, clang::CodeGen::CodeGenFunction*) + 249
15 clang           0x0000000000779f2f
clang::CodeGen::CodeGenModule::EmitGlobalVarDefinition(clang::VarDecl const*) +
79
16 clang           0x000000000077cd6c
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 156
17 clang           0x000000000077d305
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 821
18 clang           0x000000000077d59b
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 251
19 clang           0x00000000007703c1
20 clang           0x000000000076ec10
21 clang           0x000000000089fd8d clang::ParseAST(clang::Sema&, bool) + 173
22 clang           0x000000000076f7e3 clang::CodeGenAction::ExecuteAction() +
51
23 clang           0x000000000068793b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 283
24 clang           0x0000000000669f42
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1154
25 clang           0x00000000006615b0 cc1_main(char const**, char const**, char
const*, void*) + 704
26 clang           0x0000000000668c82 main + 3090
27 libc.so.6       0x00007f8a5b794cdd __libc_start_main + 253
28 clang           0x0000000000661129
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name a.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.20.1.20100303
-resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 99
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-FjV6mE.o
-x c a.c 
1.    a.c:1:27: current parser token 'int'
2.    a.c:1:6: LLVM IR generation of declaration 'foo'
3.    a.c:1:6: Generating code for declaration 'foo'
clang: error: unable to execute command: Aborted
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  Wed Nov 24 21:07:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 21:07:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 8692] New: use of default argument to function that
 is declared later in class
Message-ID: <bug-8692-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8692

           Summary: use of default argument to function that is declared
                    later in class
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: timoskrempel at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following program is valid c++ and generates an error with clang++ but
works fine in g++:

$ cat main.cc
class A
{
  public:
    class B
    {
      public:
    B(int i=1)
      {}
    };

    A(B b = B())
      {}

};

int main()
{
  A a;
}


$ clang++ main.cc
main.cc:11:13: error: use of default argument to function 'B' that is declared
      later in class 'B'
    A(B b = B())
            ^
main.cc:7:10: note: default argument declared here
        B(int i=1)
                ^
1 error generated.

$ clang++ -v
clang version 2.8 (branches/release_28)
Target: x86_64-pc-linux-gnu
Thread model: posix

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Nov 24 22:00:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 24 Nov 2010 22:00:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8693] New: crash during precompile header build
Message-ID: <bug-8693-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8693

           Summary: crash during precompile header build
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: luc_j_bourhis at mac.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


~> clang++ --version
clang version 2.9 (trunk 120113)
Target: x86_64-apple-darwin10
Thread model: posix

~> cat pre.h
#include <boost/python.hpp>

~> export BOOST_ROOT=<top level directory of the Boost C++ library distro>

~> clang++ -o pre.h.gch -c -DBOOST_ALL_NO_LIB -DBOOST_DISABLE_THREADS
-DBOOST_PYTHON_MAX_BASES=2 -I$BOOST_ROOT -x c++-header -fPIC
-fno-strict-aliasing -DNDEBUG -O3 -ffast-math
-I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6
pre.h

Assertion failed: (getValueKind() == VK_LValue), function ClassifyImpl, file
ExprClassification.cpp, line 69.
0  clang             0x0000000100d444b2 std::vector<llvm::sys::Path,
std::allocator<llvm::sys::Path>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::sys::Path*,
std::vector<llvm::sys::Path, std::allocator<llvm::sys::Path> > >,
llvm::sys::Path const&) + 8850
1  clang             0x0000000100d44a59 std::vector<llvm::sys::Path,
std::allocator<llvm::sys::Path>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::sys::Path*,
std::vector<llvm::sys::Path, std::allocator<llvm::sys::Path> > >,
llvm::sys::Path const&) + 10297
2  libSystem.B.dylib 0x00007fff85ec167a _sigtramp + 26
3  clang             0x000000010023425e
clang::Parser::LateParsedMethodDeclaration::~LateParsedMethodDeclaration() +
33630
4  clang             0x000000010000e186
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&) + 3606
5  clang             0x000000010000e148
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&) + 3544
6  clang             0x00000001005c5363
clang::CXXStaticCastExpr::~CXXStaticCastExpr() + 371
7  clang             0x00000001005c5f1b
clang::CXXStaticCastExpr::~CXXStaticCastExpr() + 3371
8  clang             0x00000001005ba06f
llvm::FoldingSet<clang::CXXSpecialName>::ComputeNodeHash(llvm::FoldingSetImpl::Node*,
llvm::FoldingSetNodeID&) const + 35455
9  clang             0x0000000100278a15
std::vector<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation>,
std::allocator<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation>*,
std::vector<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation>,
std::allocator<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation> > > >, std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation> const&) + 709
10 clang             0x0000000100278963
std::vector<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation>,
std::allocator<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation> >
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation>*,
std::vector<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation>,
std::allocator<std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation> > > >, std::pair<clang::VisibilityAttr::VisibilityType,
clang::SourceLocation> const&) + 531
11 clang             0x000000010024575d
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 31325
12 clang             0x00000001002401a7
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 9383
13 clang             0x000000010024001e
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 8990
14 clang             0x000000010023df02
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 514
15 clang             0x000000010023de74
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 372
16 clang             0x0000000100245708
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 31240
17 clang             0x00000001002401a7
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 9383
18 clang             0x000000010023df02
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 514
19 clang             0x000000010023de74
std::deque<clang::Parser::ParsingClass*,
std::allocator<clang::Parser::ParsingClass*> >::_M_reallocate_map(unsigned
long, bool) + 372
20 clang             0x00000001002552a6
clang::PragmaWeakHandler::~PragmaWeakHandler() + 9750
21 clang             0x0000000100253170
clang::PragmaWeakHandler::~PragmaWeakHandler() + 1248
22 clang             0x0000000100255df1
clang::PragmaWeakHandler::~PragmaWeakHandler() + 12641
23 clang             0x0000000100256850
clang::PragmaWeakHandler::~PragmaWeakHandler() + 15296
24 clang             0x000000010022b62f clang::MSP430InterruptAttr*
clang::Decl::getAttr<clang::MSP430InterruptAttr>() const + 4799
25 clang             0x000000010022afd5 clang::MSP430InterruptAttr*
clang::Decl::getAttr<clang::MSP430InterruptAttr>() const + 3173
26 clang             0x000000010023b40f clang::Decl**
llvm::SmallVectorImpl<clang::Decl*>::insert<clang::Decl**>(clang::Decl**,
clang::Decl**, clang::Decl**) + 16911
27 clang             0x000000010023aaa3 clang::Decl**
llvm::SmallVectorImpl<clang::Decl*>::insert<clang::Decl**>(clang::Decl**,
clang::Decl**, clang::Decl**) + 14499
28 clang             0x000000010022e8ad
clang::Parser::LateParsedMethodDeclaration::~LateParsedMethodDeclaration() +
10669
29 clang             0x0000000100257972
clang::PragmaWeakHandler::~PragmaWeakHandler() + 19682
30 clang             0x000000010025754d
clang::PragmaWeakHandler::~PragmaWeakHandler() + 18621
31 clang             0x00000001002571fc
clang::PragmaWeakHandler::~PragmaWeakHandler() + 17772
32 clang             0x000000010022d8be
clang::Parser::LateParsedMethodDeclaration::~LateParsedMethodDeclaration() +
6590
33 clang             0x000000010025e0cc
clang::PragmaWeakHandler::~PragmaWeakHandler() + 46140
34 clang             0x00000001002378f0 clang::Decl**
llvm::SmallVectorImpl<clang::Decl*>::insert<clang::Decl**>(clang::Decl**,
clang::Decl**, clang::Decl**) + 1776
35 clang             0x000000010022d9c6
clang::Parser::LateParsedMethodDeclaration::~LateParsedMethodDeclaration() +
6854
36 clang             0x000000010025e0cc
clang::PragmaWeakHandler::~PragmaWeakHandler() + 46140
37 clang             0x00000001002378f0 clang::Decl**
llvm::SmallVectorImpl<clang::Decl*>::insert<clang::Decl**>(clang::Decl**,
clang::Decl**, clang::Decl**) + 1776
38 clang             0x000000010022d9c6
clang::Parser::LateParsedMethodDeclaration::~LateParsedMethodDeclaration() +
6854
39 clang             0x000000010025e0cc
clang::PragmaWeakHandler::~PragmaWeakHandler() + 46140
40 clang             0x000000010025d98d
clang::PragmaWeakHandler::~PragmaWeakHandler() + 44285
41 clang             0x000000010022a750 clang::MSP430InterruptAttr*
clang::Decl::getAttr<clang::MSP430InterruptAttr>() const + 992
42 clang             0x0000000100035f07 llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 10647
43 clang             0x00000001000163ca std::_Rb_tree<std::string, std::string,
std::_Identity<std::string>, std::less<std::string>,
std::allocator<std::string> >::_M_insert_unique(std::string const&) + 3290
44 clang             0x000000010000f986
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&) + 9750
45 clang             0x0000000100012c83 std::vector<llvm::SourceMgr::SrcBuffer,
std::allocator<llvm::SourceMgr::SrcBuffer>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::SourceMgr::SrcBuffer*,
std::vector<llvm::SourceMgr::SrcBuffer,
std::allocator<llvm::SourceMgr::SrcBuffer> > >, llvm::SourceMgr::SrcBuffer
const&) + 1379
46 clang             0x000000010000e3a4
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&) + 4148
47 clang             0x0000000000000030
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&) + 4294913216
Stack dump:
0.    Program arguments: /usr/local/Cellar/clang/trunk/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -emit-pch -disable-free -main-file-name pre.h
-pic-level 2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 97.2 -resource-dir
/usr/local/Cellar/clang/trunk/bin/../lib/clang/2.9 -D BOOST_ALL_NO_LIB -D
BOOST_DISABLE_THREADS -D BOOST_PYTHON_MAX_BASES=2 -D NDEBUG -I
/Users/luc/Developer/cctbx/boost -I
/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -O3
-ferror-limit 19 -fmessage-length 104 -stack-protector 1 -fblocks -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o pre.h.gch -x c++-header pre.h 
1.    /Users/luc/Developer/cctbx/boost/boost/utility/addressof.hpp:40:75:
current parser token ')'
2.    /Users/luc/Developer/cctbx/boost/boost/utility/addressof.hpp:18:1:
parsing namespace 'boost'
3.    /Users/luc/Developer/cctbx/boost/boost/utility/addressof.hpp:21:1:
parsing namespace 'detail'
4.    /Users/luc/Developer/cctbx/boost/boost/utility/addressof.hpp:35:19:
parsing struct/union/class body 'addressof_impl'
5.    /Users/luc/Developer/cctbx/boost/boost/utility/addressof.hpp:38:5:
parsing function body 'f'
6.    /Users/luc/Developer/cctbx/boost/boost/utility/addressof.hpp:38:5: in
compound statement ('{}')
clang: error: unable to execute command: Illegal instruction
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 Nov 25 04:01:39 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Nov 2010 04:01:39 -0600 (CST)
Subject: [LLVMbugs] [Bug 8694] New: Analyzer crashes when forward enum
 pointer is passed as int pointer
Message-ID: <bug-8694-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8694

           Summary: Analyzer crashes when forward enum pointer is passed
                    as int pointer
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: magnus.reftel at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The following test case makes the analyzer segfault:


void sub(int* e)
{
}

void crash(enum E* e)
{
        sub(e);
}


Adding "enum E{whatever};" at the top makes the crash go away. The error
message is:


$ /opt/llvm-r120134/bin/clang --analyze -v crash.c
clang version 2.9 (trunk 120134)
Target: i386-pc-cygwin
Thread model: posix
 "/opt/llvm-r120134/bin/clang" -cc1 -triple i386-pc-cygwin -analyze
-disable-free -main-file-name crash.c -analyzer-store=region
-analyzer-opt-analyze-nested-blocks -analyzer-check-dead-stores
-analyzer-check-objc-mem -analyzer-eagerly-assume
-analyzer-check-objc-methodsigs -analyzer-check-objc-unused-ivars
-analyzer-check-idempotent-operations -analyzer-output plist -w
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu
pentium4 -target-linker-version 2.20.51.20100410 -v -resource-dir
/opt/llvm-r120134/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 80
-fno-use-cxa-atexit -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o crash.plist -x c crash.c
clang -cc1 version 2.9 based upon llvm 2.9svn hosted on i386-pc-cygwin
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/llvm-r120134/bin/../lib/clang/2.9/include
 /usr/include/w32api
 /usr/include
End of search list.
Stack dump:
0.      Program arguments: /opt/llvm-r120134/bin/clang -cc1 -triple
i386-pc-cygwin -analyze -disable-free -main-file-name crash.c
-analyzer-store=region -analyzer-opt-analyze-nested-blocks
-analyzer-check-dead-stores -analyzer-check-objc-mem -analyzer-eagerly-assume
-analyzer-check-objc-methodsigs -analyzer-check-objc-unused-ivars
-analyzer-check-idempotent-operations -analyzer-output plist -w
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu
pentium4 -target-linker-version 2.20.51.20100410 -v -resource-dir
/opt/llvm-r120134/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 80
-fno-use-cxa-atexit -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o crash.plist -x c crash.c
1.      crash.c:7:21: current parser token ')'
2.      crash.c:6:1: parsing function body 'crash'
3.      crash.c:6:1: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)



I believe this is and old problem that was fixed about two weeks ago, but now
fails again.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Nov 25 05:16:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Nov 2010 05:16:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 8695] New: clang crashes for objc method using a
 bitwise-struct with enum
Message-ID: <bug-8695-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8695

           Summary: clang crashes for objc method using a bitwise-struct
                    with enum
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Tam at SiuLung.com
                CC: llvmbugs at cs.uiuc.edu


The following Objective-C program crashes clang 2.8:

typedef enum { A1, A2 } A;
typedef struct { A a : 1; } B;
@interface Obj { B *b; } @end
@implementation Obj @end

Crash happens at clang::ASTContext::getObjCEncodingForTypeImpl(clang:QualType,
std::string&, bool, bool, clang::FieldDecl const *, bool, bool).

Defining an objective-c message that takes in a (B *) parameter or returns (B
*) produces the same 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 Nov 25 07:11:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Nov 2010 07:11:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 8687] [MC assembler] default suffix of fld mnemonic?
In-Reply-To: <bug-8687-206@http.llvm.org/bugs/>
References: <bug-8687-206@http.llvm.org/bugs/>
Message-ID: <20101125131150.AE8A82A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8687

Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru> 2010-11-25 07:11:50 CST ---
Ok, this is expected behavior. Please fix the bogus sources.

*** This bug has been marked as a duplicate of bug 8528 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Nov 25 12:20:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Nov 2010 12:20:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 8696] New: Optimizations not done without platform
	parameters
Message-ID: <bug-8696-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8696

           Summary: Optimizations not done without platform parameters
           Product: new-bugs
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


The strcopy and optimizations are not used when there's no platform data
(espeacially the alignment information).

There are two ways to fix that:
a) an additional parameter to opt or llvm-ld that auto-injects the platform
data or use the native platform
b) a command line tool that outputs the recommendend alignment settings on each
platform to get the best speed

thanks for implementing ;)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Nov 25 15:41:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 25 Nov 2010 15:41:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 8697] New: Field access results in a dereference of
 a null pointer (loaded from variable 'l')
Message-ID: <bug-8697-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8697

           Summary: Field access results in a dereference of a null
                    pointer (loaded from variable 'l')
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: zdenek.kabelac at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Bug reported by the clang static analyzer.

Description: Field access results in a dereference of a null pointer (loaded
from variable 'l')
File: lvm2.git/lib/config/config.c
Line: 618

This case seems to be quite clear - allocated area for root node is in fact
memset() to 0 - but analyzer seems to think there is chance to have path 
!root->child not executed first - so gives false positive about possible null
dereference.

As an easy hack could be used   'root->child = NULL'  after root node is
allocated - but that's ugly.

Is there a way to instrument with same attribute that given array is zeroed?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Nov 26 08:59:29 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Nov 2010 08:59:29 -0600 (CST)
Subject: [LLVMbugs] [Bug 8698] New: Internal compiler error on logical
 and/or of floating-point expression
Message-ID: <bug-8698-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8698

           Summary: Internal compiler error on logical and/or of
                    floating-point expression
           Product: dragonegg
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: bugzilla at lklundin.dk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5835)
 --> (http://llvm.org/bugs/attachment.cgi?id=5835)
Logical-or-program to trigger internal compiler error

The attached 3 lines of source code causes the command
llvm-gcc -c -o /dev/null cpl_geom_img.c -std=c99
to fail with

*** 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
cpl_geom_img.c: In function ?my_func?:
cpl_geom_img.c:2:5: internal compiler error: in build_binary_op, at
c-typeck.c:9849
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.5/README.Bugs> for instructions.

on a 32-bit Ubuntu 10.10 installation.

The compilation also fails with -std=c89 (and -std=iso9899:199409).

The compilation also fails if the type is changed from double to float.

The compilation does not fail if the floating-point expression is compared to
0.0.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Nov 26 11:31:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 26 Nov 2010 11:31:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8699] New: Store of 3 constant bytes should be
 combined into one i24 store (regression)
Message-ID: <bug-8699-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8699

           Summary: Store of 3 constant bytes should be combined into one
                    i24 store (regression)
           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: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


The element_copy.adb test from FrontendAda started failing some time ago.  The
numbers 2, 72 and 105 are stored into three consecutive bytes.  Previously this
was turned into one i24 store of 6899714, but no longer: running "opt
-std-compile-opts" on the attached testcase no longer performs this
optimization.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Nov 27 03:16:27 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Nov 2010 03:16:27 -0600 (CST)
Subject: [LLVMbugs] [Bug 8700] New: clang++ accepts storage class on
 explicit template specialization
Message-ID: <bug-8700-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8700

           Summary: clang++ accepts storage class on explicit template
                    specialization
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


example code:

template<typename T>
static void foo();

template<>
static void foo<void>();

g++ 4.3 and higher will reject this code with "error: explicit template
specialization cannot have a storage class". This is core defect #605
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#605

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Nov 27 05:18:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Nov 2010 05:18:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 8698] Internal compiler error on logical and/or of
 floating-point expression
In-Reply-To: <bug-8698-206@http.llvm.org/bugs/>
References: <bug-8698-206@http.llvm.org/bugs/>
Message-ID: <20101127111826.981622A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8698

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2010-11-27 05:18:25 CST ---
This is not a dragonegg issue.  If you use gcc-4.5 from ubuntu 10.10 without
dragonegg it crashes in the same way:

$ gcc-4.5 -c -o /dev/null cpl_geom_img.c -std=c99 -O1
cpl_geom_img.c: In function 'my_func':
cpl_geom_img.c:2:5: internal compiler error: in build_binary_op, at
c-typeck.c:9849
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.5/README.Bugs> for instructions.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Nov 27 08:09:46 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Nov 2010 08:09:46 -0600 (CST)
Subject: [LLVMbugs] [Bug 8701] New: Completely overlapping memcpys not
	eliminated
Message-ID: <bug-8701-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8701

           Summary: Completely overlapping memcpys not eliminated
           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


This C code:

===
#include <string.h>

char string1[12];

void foo() {
  memcpy(string1, "Hello World", 12);
  memcpy(string1, "Hello World", 12);
}
===

optimizes to:

===
@string1 = common global [12 x i8] zeroinitializer, align 1
@.str = private constant [12 x i8] c"Hello World\00"

define void @foo() nounwind ssp {
entry:
  tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* getelementptr inbounds ([12 x
i8]* @string1, i64 0, i64 0), i8* getelementptr inbounds ([12 x i8]* @.str, i64
0, i64 0), i64 12, i32 1, i1 false)
  tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* getelementptr inbounds ([12 x
i8]* @string1, i64 0, i64 0), i8* getelementptr inbounds ([12 x i8]* @.str, i64
0, i64 0), i64 12, i32 1, i1 false)
  ret void
}

declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, i64, i32,
i1) nounwind
===

the first memcpy is completely superfluous and should be eliminated.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Nov 27 14:48:47 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 27 Nov 2010 14:48:47 -0600 (CST)
Subject: [LLVMbugs] [Bug 8659] tcmalloc in Chromium segfaults when compiled
 with both -fPIC and integrated-as
In-Reply-To: <bug-8659-206@http.llvm.org/bugs/>
References: <bug-8659-206@http.llvm.org/bugs/>
Message-ID: <20101127204847.AE23D2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8659

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #17 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2010-11-27 14:48:46 CST ---
Probably fixed in 120225.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 00:35:48 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 00:35:48 -0600 (CST)
Subject: [LLVMbugs] [Bug 5413] \u in wide string literals is broken
In-Reply-To: <bug-5413-206@http.llvm.org/bugs/>
References: <bug-5413-206@http.llvm.org/bugs/>
Message-ID: <20101128063548.ECCA42A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=5413

Nico Weber <nicolasweber at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Nico Weber <nicolasweber at gmx.de> 2010-11-28 00:35:48 CST ---
I fixed this a while ago.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 10:41:15 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 10:41:15 -0600 (CST)
Subject: [LLVMbugs] [Bug 8683] clang crash on parenthesized initialization
 of type with nontrivial copy ctor and copy assignment
In-Reply-To: <bug-8683-206@http.llvm.org/bugs/>
References: <bug-8683-206@http.llvm.org/bugs/>
Message-ID: <20101128164115.DEF212A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8683

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andersca at mac.com
         Resolution|                            |FIXED

--- Comment #1 from Anders Carlsson <andersca at mac.com> 2010-11-28 10:41:15 CST ---
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20101122/036793.html

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 12:17:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 12:17:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 8702] New: opt -loop-rotate never completes
Message-ID: <bug-8702-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8702

           Summary: opt -loop-rotate never completes
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5837)
 --> (http://llvm.org/bugs/attachment.cgi?id=5837)
bugpoint-reduced-simplified.bc

llvm/clang r120239

$ opt bugpoint-reduced-simplified.bc -loop-rotate

Testcase reduced from FreeBSD in_mcast.c with KTR defined.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 13:16:16 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 13:16:16 -0600 (CST)
Subject: [LLVMbugs] [Bug 8695] clang crashes for objc method using a
 bitwise-struct with enum
In-Reply-To: <bug-8695-206@http.llvm.org/bugs/>
References: <bug-8695-206@http.llvm.org/bugs/>
Message-ID: <20101128191616.DD25B2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8695

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-11-28 13:16:16 CST ---
Verified, works on ToT.  Alan, if this is still failing for you, please reopen
with more info to reproduce, 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  Sun Nov 28 14:24:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 14:24:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 8686] [MC assembler] 'b' suffix on 'setxx'
 mnemonics not accepted
In-Reply-To: <bug-8686-206@http.llvm.org/bugs/>
References: <bug-8686-206@http.llvm.org/bugs/>
Message-ID: <20101128202401.BF1982A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8686

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-28 14:24:01 CST ---
Fixed in r120260, 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  Sun Nov 28 14:24:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 14:24:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8688] Copying block that captures itself in its
 declaration leads to garbage
In-Reply-To: <bug-8688-206@http.llvm.org/bugs/>
References: <bug-8688-206@http.llvm.org/bugs/>
Message-ID: <20101128202445.3E3042A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8688

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-28 14:24:44 CST ---
This is correct behavior, equivalent to:

  int x = x+1;

"don't do that".

-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  Sun Nov 28 14:26:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 14:26:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 8691] clang fails to compile big static arrays
In-Reply-To: <bug-8691-206@http.llvm.org/bugs/>
References: <bug-8691-206@http.llvm.org/bugs/>
Message-ID: <20101128202653.B47C42A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8691

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-28 14:26:52 CST ---
Unfortunate but true, the required IR enhancement to support this sort of thing
is tracked by PR1324

*** This bug has been marked as a duplicate of bug 1324 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:31:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:31:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 1827] fail to analyze quadratic loop example
In-Reply-To: <bug-1827-206@http.llvm.org/bugs/>
References: <bug-1827-206@http.llvm.org/bugs/>
Message-ID: <20101128213150.6254A2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=1827

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Chris Lattner <clattner at apple.com> 2010-11-28 15:31:48 CST ---
The miscompilation and crash are fixed here, if the really tiny missed
optimization is important, please move it to Targets/README.txt

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:34:14 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:34:14 -0600 (CST)
Subject: [LLVMbugs] [Bug 2571] Shootout-C++/ackermann has gcc/llc of 0.23x
	on Linux
In-Reply-To: <bug-2571-206@http.llvm.org/bugs/>
References: <bug-2571-206@http.llvm.org/bugs/>
Message-ID: <20101128213414.349C32A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=2571

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-28 15:34:13 CST ---
this seems to be fine for me on a mac: llc is 2.1s, gcc is 2.3s.  If this is
still a problem on linux, please do some analysis to find out what the problem
is before reopening.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:34:21 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:34:21 -0600 (CST)
Subject: [LLVMbugs] [Bug 2571] Shootout-C++/ackermann has gcc/llc of 0.23x
	on Linux
In-Reply-To: <bug-2571-206@http.llvm.org/bugs/>
References: <bug-2571-206@http.llvm.org/bugs/>
Message-ID: <20101128213421.7349E2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=2571

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |WORKSFORME

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:35:54 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:35:54 -0600 (CST)
Subject: [LLVMbugs] [Bug 2852] fold load (strchr/memchr ptr, c) --> c
In-Reply-To: <bug-2852-206@http.llvm.org/bugs/>
References: <bug-2852-206@http.llvm.org/bugs/>
Message-ID: <20101128213554.5DC292A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=2852

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |LATER

--- Comment #8 from Chris Lattner <clattner at apple.com> 2010-11-28 15:35:53 CST ---
Nick, please move this to Targets/README.txt

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:36:31 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:36:31 -0600 (CST)
Subject: [LLVMbugs] [Bug 2981] Vector logic does not get optimized
In-Reply-To: <bug-2981-206@http.llvm.org/bugs/>
References: <bug-2981-206@http.llvm.org/bugs/>
Message-ID: <20101128213631.7A3352A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=2981

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #13 from Chris Lattner <clattner at apple.com> 2010-11-28 15:36:29 CST ---
No update, this is probably fixed.  Please open a new bug for any remaining
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  Sun Nov 28 15:37:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:37:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 3129] [fsf gcc bug] llvm-gcc infinite loop memory
	muncher
In-Reply-To: <bug-3129-206@http.llvm.org/bugs/>
References: <bug-3129-206@http.llvm.org/bugs/>
Message-ID: <20101128213701.897A22A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=3129

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-11-28 15:37:00 CST ---
We're not fixing generic gcc frontend bugs anymore.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:39:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:39:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 3369] [llvm-gcc frontend] math error at all
	optimization levels
In-Reply-To: <bug-3369-206@http.llvm.org/bugs/>
References: <bug-3369-206@http.llvm.org/bugs/>
Message-ID: <20101128213945.D6DB02A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=3369

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Chris Lattner <clattner at apple.com> 2010-11-28 15:39:44 CST ---
The frontend bug is fixed.  If the bug in comment #4 is still valid, it should
be filed as a new bug.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:46:17 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:46:17 -0600 (CST)
Subject: [LLVMbugs] [Bug 4114] lli brings in tons of useless dependencies
In-Reply-To: <bug-4114-206@http.llvm.org/bugs/>
References: <bug-4114-206@http.llvm.org/bugs/>
Message-ID: <20101128214617.4BFB72A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=4114

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |LATER

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-11-28 15:46:16 CST ---
Yep, but noone seems interested in working 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  Sun Nov 28 15:47:42 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:47:42 -0600 (CST)
Subject: [LLVMbugs] [Bug 4749] StrongPhiElimination losts a copy
In-Reply-To: <bug-4749-206@http.llvm.org/bugs/>
References: <bug-4749-206@http.llvm.org/bugs/>
Message-ID: <20101128214742.C661E2A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=4749

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |LATER

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-11-28 15:47:41 CST ---
StrongPhiElimination isn't production quality and noone is working on it.  It
should be removed from mainline if noone is going to maintain it.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:49:59 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:49:59 -0600 (CST)
Subject: [LLVMbugs] [Bug 5027] System library should support pipe in
	executeandwait
In-Reply-To: <bug-5027-206@http.llvm.org/bugs/>
References: <bug-5027-206@http.llvm.org/bugs/>
Message-ID: <20101128214959.433802A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=5027

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |LATER

--- Comment #7 from Chris Lattner <clattner at apple.com> 2010-11-28 15:49:58 CST ---
This isn't compelling for the clang driver, since it should use the integrated
assembler on targets that people care to invest in.   I suspect lit has lots of
other lower hanging fruit.  In any case, the presence of this bug isn't going
to increase the odds of it happening.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 15:53:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 15:53:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 7365] addr2line/gdb fail to show line information
 and source code
In-Reply-To: <bug-7365-206@http.llvm.org/bugs/>
References: <bug-7365-206@http.llvm.org/bugs/>
Message-ID: <20101128215322.53C532A6C133@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=7365

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-11-28 15:53:20 CST ---
If this is a binutils bug, it should be worked around by us now using the
integrated assembler on ELF targets.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 16:17:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 16:17:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 8688] Copying block that captures itself in its
 declaration leads to garbage
In-Reply-To: <bug-8688-206@http.llvm.org/bugs/>
References: <bug-8688-206@http.llvm.org/bugs/>
Message-ID: <20101128221722.24CE02A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8688

Kevin Ballard <kevin at sb.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #3 from Kevin Ballard <kevin at sb.org> 2010-11-28 16:17:21 CST ---
I'm really not sure what proper etiquette is for reopening bugs, so I hope it's
ok that I'm reopening this one. As I said in my previous comment, the current
behavior is not, in fact, equivalent to that int x case. Either this should
work properly, or the compiler should complain. The current behavior is simply
not right.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 18:45:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 18:45:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 8693] crash during precompile header build
In-Reply-To: <bug-8693-206@http.llvm.org/bugs/>
References: <bug-8693-206@http.llvm.org/bugs/>
Message-ID: <20101129004553.33C182A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8693

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #4 from John McCall <rjmccall at apple.com> 2010-11-28 18:45:52 CST ---
Also, this is duplicate.

*** This bug has been marked as a duplicate of bug 8681 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Nov 28 23:48:45 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 28 Nov 2010 23:48:45 -0600 (CST)
Subject: [LLVMbugs] [Bug 8695] clang crashes for objc method using a
 bitwise-struct with enum
In-Reply-To: <bug-8695-206@http.llvm.org/bugs/>
References: <bug-8695-206@http.llvm.org/bugs/>
Message-ID: <20101129054845.B873B2A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8695

Alan Tam <Tam at SiuLung.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #3 from Alan Tam <Tam at SiuLung.com> 2010-11-28 23:48:45 CST ---
While not exactly knowing what "ToT" means to you, I tried again with a fresh
svn checkout from trunk.

sltam at maple:~/llvm/build$ Release+Asserts/bin/clang --version
clang version 2.9 (trunk 120281)
Target: x86_64-unknown-linux-gnu
Thread model: posix


sltam at maple:~/llvm/build$ Release+Asserts/bin/clang -v -c a.m
clang version 2.9 (trunk 120281)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/home/sltam/llvm/build/Release+Asserts/bin/clang" -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
a.m -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.51 -v -resource-dir
/home/sltam/llvm/build/Release+Asserts/bin/../lib/clang/2.9 -ferror-limit 19
-fmessage-length 246 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o a.o -x objective-c a.m
clang -cc1 version 2.9 based upon llvm 2.9svn hosted on
x86_64-unknown-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /home/sltam/llvm/build/Release+Asserts/bin/../lib/clang/2.9/include
 /usr/include
End of search list.
0  clang           0x0000000001696bcf
1  clang           0x0000000001698e42
2  libpthread.so.0 0x00007f6de348fb40
3  clang           0x0000000000c088d9
4  clang           0x0000000000c0ade6
5  clang           0x0000000000c0b1ce
clang::ASTContext::getObjCEncodingForTypeImpl(clang::QualType, std::string&,
bool, bool, clang::FieldDecl const*, bool, bool) + 286
6  clang           0x0000000000c0b969
clang::ASTContext::getObjCEncodingForTypeImpl(clang::QualType, std::string&,
bool, bool, clang::FieldDecl const*, bool, bool) + 2233
7  clang           0x0000000000c0b4c5
clang::ASTContext::getObjCEncodingForTypeImpl(clang::QualType, std::string&,
bool, bool, clang::FieldDecl const*, bool, bool) + 1045
8  clang           0x0000000000c0c016
clang::ASTContext::getObjCEncodingForType(clang::QualType, std::string&,
clang::FieldDecl const*) + 38
9  clang           0x00000000007fdbfe
10 clang           0x000000000075587f
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 655
11 clang           0x0000000000748641
12 clang           0x00000000007469a1
13 clang           0x00000000008752f6 clang::ParseAST(clang::Sema&, bool) + 166
14 clang           0x00000000007479f4 clang::CodeGenAction::ExecuteAction() +
68
15 clang           0x0000000000641b35
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
16 clang           0x00000000006218ac
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1260
17 clang           0x0000000000619635 cc1_main(char const**, char const**, char
const*, void*) + 693
18 clang           0x0000000000620825 main + 4181
19 libc.so.6       0x00007f6de2778d8e __libc_start_main + 254
20 clang           0x0000000000617d49
Stack dump:
0.    Program arguments: /home/sltam/llvm/build/Release+Asserts/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name a.m -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.51 -v -resource-dir
/home/sltam/llvm/build/Release+Asserts/bin/../lib/clang/2.9 -ferror-limit 19
-fmessage-length 246 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o a.o -x objective-c a.m 
1.    <eof> parser at end of file
2.    a.m:4:1: LLVM IR generation of declaration 'Obj'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 03:05:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 03:05:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 8703] New: Can't compile test code using unwind.h
Message-ID: <bug-8703-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8703

           Summary: Can't compile test code using unwind.h
           Product: clang
           Version: unspecified
          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


[~]> clang -v
clang version 2.9 (trunk 120281)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[~]> cat test.c
#include <unwind.h>

int main ()
{
    struct _Unwind_Exception exc;
    struct _Unwind_Context *context;
    _Unwind_GetCFA (context);

    return 0;
}

[~]> clang test.c   
In file included from test.c:1:
/usr/lib64/gcc/x86_64-suse-linux/4.5/include/unwind.h:43:46: error: unknown
machine mode '__unwind_word__'
typedef unsigned _Unwind_Word __attribute__((__mode__(__unwind_word__)));
                                             ^
/usr/lib64/gcc/x86_64-suse-linux/4.5/include/unwind.h:44:45: error: unknown
machine mode '__unwind_word__'                        
typedef signed _Unwind_Sword __attribute__((__mode__(__unwind_word__)));
                                            ^
2 errors generated.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 11:24:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 11:24:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 8678] Destructors are not called for C++ temp
 objects that are created when C++ objects are copied via ObjC dot syntax
In-Reply-To: <bug-8678-206@http.llvm.org/bugs/>
References: <bug-8678-206@http.llvm.org/bugs/>
Message-ID: <20101129172403.C03452A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8678

Fariborz Jahanian <fjahanian at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #1 from Fariborz Jahanian <fjahanian at apple.com> 2010-11-29 11:24:03 CST ---
All likelihood it is duplicate of[Bug 8653].

*** This bug has been marked as a duplicate of bug 8653 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 12:04:28 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 12:04:28 -0600 (CST)
Subject: [LLVMbugs] [Bug 8668] Use of multiple using declaration in a
 function scope (Another erroneous compilation)
In-Reply-To: <bug-8668-206@http.llvm.org/bugs/>
References: <bug-8668-206@http.llvm.org/bugs/>
Message-ID: <20101129180428.31CEF2A6C130@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8668

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |INVALID

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-11-29 12:04:27 CST ---
Doug Gregor pointed out that I was over-hasty about resolving this. 
Redeclarations are actually permitted in every scope except classes;  it's just
that most declarations in local scopes are definitions.  So this is invalid.

I've reverted my fix.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 12:19:44 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 12:19:44 -0600 (CST)
Subject: [LLVMbugs] [Bug 8479] clang evaluates visibility of default
 parameters at the call site instead of at parameter definition site
In-Reply-To: <bug-8479-206@http.llvm.org/bugs/>
References: <bug-8479-206@http.llvm.org/bugs/>
Message-ID: <20101129181944.36E462A6C131@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8479

Nico Weber <nicolasweber at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Nico Weber <nicolasweber at gmx.de> 2010-11-29 12:19:43 CST ---
r120299

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 15:02:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 15:02:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 8689] false positive due to not analyzing value
	dependencies
In-Reply-To: <bug-8689-206@http.llvm.org/bugs/>
References: <bug-8689-206@http.llvm.org/bugs/>
Message-ID: <20101129210240.448CB2A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8689

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kremenek at apple.com
         Resolution|                            |INVALID

--- Comment #5 from Ted Kremenek <kremenek at apple.com> 2010-11-29 15:02:39 CST ---
This looks like a completely legit warning from the analyzer.  Why is this a
false positive?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 15:59:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 15:59:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 8677] likely integer wrong code bug
In-Reply-To: <bug-8677-206@http.llvm.org/bugs/>
References: <bug-8677-206@http.llvm.org/bugs/>
Message-ID: <20101129215956.7D23B2A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8677

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-11-29 15:59:56 CST ---
Patch looks great to me, I committed it with an expanded comment in r120325,
thanks Jakub!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 17:21:40 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 17:21:40 -0600 (CST)
Subject: [LLVMbugs] [Bug 8694] Sema crashes when forward enum pointer is
 passed as int pointer
In-Reply-To: <bug-8694-206@http.llvm.org/bugs/>
References: <bug-8694-206@http.llvm.org/bugs/>
Message-ID: <20101129232140.698962A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8694

Fariborz Jahanian <fjahanian at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fjahanian at apple.com
         Resolution|                            |FIXED

--- Comment #4 from Fariborz Jahanian <fjahanian at apple.com> 2010-11-29 17:21:39 CST ---
Fixed in r 120345.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 19:31:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 19:31:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 8704] New: LLVM/Clang unexpectedly generates ivar
 for readonly properties
Message-ID: <bug-8704-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8704

           Summary: LLVM/Clang unexpectedly generates ivar for readonly
                    properties
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nfarina at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I'm using the new iOS 4.2 SDK and LLVM 1.6, and I've been trying the new
"@synthesize by default" feature which is _awesome_. (using -Xclang and
-fobjc-nonfragile-abi2)

However I've noticed an odd side effect: Clang seems to be "automatically
synthesizing" and declaring ivars for readonly properties for which I've
defined a "getter" method.

Example Object:

@interface TestObject : NSObject
@property (nonatomic, readonly) NSString *hello;
@end

@implementation TestObject
- (NSString *) hello { return @"world."; }
@end

Later, when inspecting the class:

    unsigned int varCount;

    Ivar *vars = class_copyIvarList([TestObject class], &varCount);

    for (int i = 0; i < varCount; i++) {
        Ivar var = vars[i];

        const char* name = ivar_getName(var);
        const char* typeEncoding = ivar_getTypeEncoding(var);

        NSLog(@"IVAR %s of type %s", name, typeEncoding);
    }

    free(vars);

Prints: IVAR hello of type @"NSString"

The problem goes away if I explicitly declare "@dynamic hello". But this seems
unnecessary: I can't imagine a case where I would want a readonly property with
an automatic ivar where I've *also* created my own getter method.

Appreciate all your guys' work on these amazing new features!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Nov 29 22:19:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 29 Nov 2010 22:19:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 8705] New: clang doesn't handle friend member
 functions correctly
Message-ID: <bug-8705-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8705

           Summary: clang doesn't handle friend member functions correctly
           Product: clang
           Version: unspecified
          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


gcc 4.2 accepts the following program:

class B {
 public:
  void b(int a);
  void c(int a);
};

class A {
 private:
  static int a();
  friend void B::c(int);
};

//void B::b(int a = A::a()) {}  // Should error
void B::c(int a = A::a()) {}

clang rejects it with

test.cc:14:22: error: 'a' is a private member of 'A'
void B::c(int a = A::a()) {}
                     ^
test.cc:9:14: note: declared private here
  static int a();
             ^
1 error generated.

(Reverting r120299 does not make this go away.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 01:21:38 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 01:21:38 -0600 (CST)
Subject: [LLVMbugs] [Bug 8573] Cannot yet select: intrinsic
	%llvm.x86.sse3.monitor
In-Reply-To: <bug-8573-206@http.llvm.org/bugs/>
References: <bug-8573-206@http.llvm.org/bugs/>
Message-ID: <20101130072138.322F72A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8573

Eric Christopher <echristo at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Eric Christopher <echristo at gmail.com> 2010-11-30 01:21:37 CST ---
Fixed thusly:

[ghostwheel:~/sources/llvm] echristo% svn ci
Sending        lib/Target/X86/X86ISelLowering.cpp
Sending        lib/Target/X86/X86ISelLowering.h
Sending        lib/Target/X86/X86InstrSSE.td
Adding         test/CodeGen/X86/apm.ll
Transmitting file data ....
Committed revision 120404.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 01:23:35 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 01:23:35 -0600 (CST)
Subject: [LLVMbugs] [Bug 8701] Completely overlapping memcpys not eliminated
In-Reply-To: <bug-8701-206@http.llvm.org/bugs/>
References: <bug-8701-206@http.llvm.org/bugs/>
Message-ID: <20101130072335.051D72A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8701

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Chris Lattner <clattner at apple.com> 2010-11-30 01:23:34 CST ---
Implemented in r120406

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 01:34:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 01:34:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 5571] LLVM-GCC Front End failed in linux kernel
 driver proceessing
In-Reply-To: <bug-5571-206@http.llvm.org/bugs/>
References: <bug-5571-206@http.llvm.org/bugs/>
Message-ID: <20101130073401.B0F802A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=5571

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |LATER

--- Comment #1 from Chris Lattner <clattner at apple.com> 2010-11-30 01:34:01 CST ---
Noone seems interested in investigating this.  Please upgrade to clang, which
doesn't have this bug.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 01:36:22 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 01:36:22 -0600 (CST)
Subject: [LLVMbugs] [Bug 8657] DSE doesn't remove small stores overwritten
 by later large ones
In-Reply-To: <bug-8657-206@http.llvm.org/bugs/>
References: <bug-8657-206@http.llvm.org/bugs/>
Message-ID: <20101130073622.A082B2A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8657

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-11-30 01:36:22 CST ---
Ok, I don't plan to handle the variable case.  The constant offset case is
tracked by PR6043.

*** This bug has been marked as a duplicate of bug 6043 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 05:50:26 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 05:50:26 -0600 (CST)
Subject: [LLVMbugs] [Bug 4087] Headers for libffi not found in
 lib/ExecutionEngine/Interpreter
In-Reply-To: <bug-4087-206@http.llvm.org/bugs/>
References: <bug-4087-206@http.llvm.org/bugs/>
Message-ID: <20101130115026.E3B122A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=4087

Magnus Reftel <magnus.reftel at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #7 from Magnus Reftel <magnus.reftel at gmail.com> 2010-11-30 05:50:25 CST ---
The actual problem was that I was specifying the include path in CFLAGS instead
of CPPFLAGS. The help message from configure clearly says how -I flags should
be added, and did it already when the issue was filed.
Problem existed between keyboard and chair. Resolving issue as invalid.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 06:26:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 06:26:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 8706] New: Assertion `Ty->isSized() && "Cannot
 getTypeInfo() on a type that is unsized!"' failed.
Message-ID: <bug-8706-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8706

           Summary: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a
                    type that is unsized!"' failed.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


(Sorry for the bad summary; anyone who has a better idea of what's going on,
feel free to change it.)

Compiling the code below with clang++ built from trunk r120423 on
x86_64-unknown-linux-gnu fails an assert:


template <typename T> class RefPtr {
 public:
  RefPtr() : m_ptr(0) {}
  typedef T *(RefPtr::*UnspecifiedBoolType);
  operator UnspecifiedBoolType() const {
    return m_ptr ? &RefPtr::m_ptr : 0;
  }
 private:
  T *m_ptr;
};

class C {};
class D {};

template <typename T> class Handle { T *val_; };

Handle<D> someFunction() {
  RefPtr <C> rp;
  bool b = rp;
}

void f() {
  (void) &someFunction;
}


clang: TargetData.cpp:495: unsigned int llvm::TargetData::getAlignment(const
llvm::Type*, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on
a type that is unsized!"' failed.
0  clang           0x00000000016a955f
1  clang           0x00000000016ab7d2
2  libpthread.so.0 0x00007f6a6d29d8f0
3  libc.so.6       0x00007f6a6c58ca75 gsignal + 53
4  libc.so.6       0x00007f6a6c5905c0 abort + 384
5  libc.so.6       0x00007f6a6c585941 __assert_fail + 241
6  clang           0x0000000001550277 llvm::TargetData::getAlignment(llvm::Type
const*, bool) const + 311
7  clang           0x000000000154fc3b
llvm::StructLayout::StructLayout(llvm::StructType const*, llvm::TargetData
const&) + 267
8  clang           0x0000000001550072
llvm::TargetData::getStructLayout(llvm::StructType const*) const + 882
9  clang           0x00000000007862b7
10 clang           0x00000000007e0240
clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(clang::DeclRefExpr const*) +
1584
11 clang           0x00000000007e300e
clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) + 782
12 clang           0x0000000000809205
13 clang           0x000000000080fd5b
14 clang           0x0000000000809e9c
15 clang           0x000000000080a917
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 87
16 clang           0x000000000085a131
clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) + 833
17 clang           0x0000000000860b08
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 264
18 clang           0x0000000000860da6
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 262
19 clang           0x000000000085dc82
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 34
20 clang           0x0000000000881ff9
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 617
21 clang           0x000000000077acd6
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl)
+ 678
22 clang           0x000000000077b7a2
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 194
23 clang           0x000000000077c7b7
clang::CodeGen::CodeGenModule::EmitDeferred() + 151
24 clang           0x000000000077c839 clang::CodeGen::CodeGenModule::Release()
+ 9
25 clang           0x000000000076d4f8
26 clang           0x000000000089bc94 clang::ParseAST(clang::Sema&, bool) + 292
27 clang           0x000000000076e454 clang::CodeGenAction::ExecuteAction() +
68
28 clang           0x00000000006682d5
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 357
29 clang           0x00000000006475ac
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1260
30 clang           0x000000000063f385 cc1_main(char const**, char const**, char
const*, void*) + 693
31 clang           0x0000000000646567 main + 4183
32 libc.so.6       0x00007f6a6c577c4d __libc_start_main + 253
33 clang           0x000000000063da99
Stack dump:
0.    Program arguments: /work/llvm/Release+Asserts/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -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.20.1 -resource-dir /work/llvm/Release+Asserts/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 141 -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o a.o -x c++ /tmp/a.cc 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    /tmp/a.cc:7:3: Generating code for declaration 'RefPtr<C>::operator class
C *class RefPtr<class C>::*'
4.    /tmp/a.cc:7:40: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 09:06:19 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 09:06:19 -0600 (CST)
Subject: [LLVMbugs] [Bug 8707] New: Blocks cannot contain static variables
 when compiled with clang, works with LLVM-GCC 4.2
Message-ID: <bug-8707-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8707

           Summary: Blocks cannot contain static variables when compiled
                    with clang, works with LLVM-GCC 4.2
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: keith at 33software.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5839)
 --> (http://llvm.org/bugs/attachment.cgi?id=5839)
Exhibits the issue described above.

Summary:

Compiled with Clang, blocks cannot contain static variables.

Attached is a source file which when compiled with clang, it exits with an
error. Compiling with LLVM-GCC 4.2 doesn't exhibit the issue.

You can pass -DFIXME to remove move the declaration outside the block, causing
it to compile successfully under Clang and LLVM-GCC 4.2.


Invocations:

$ clang MiscompiledBlockWithClang.m -framework Cocoa // exhibits issue
$ clang MiscompiledBlockWithClang.m -framework Cocoa -DFIXME // moves the
declaration, working around the issue

$ llvm-gcc-4.2 MiscompiledBlockWithClang.m -framework Cocoa // doesn't exhibit
issue


Versions:

@@@
$ clang -v
Apple clang version 1.6 (tags/Apple/clang-70)
Target: x86_64-apple-darwin10
Thread model: posix
@@@

@@@
$ llvm-gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/llvmgcc42/llvmgcc42-2333.4~7/src/configure
--disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin10
--enable-llvm=/var/tmp/llvmgcc42/llvmgcc42-2333.4~7/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2333.4)
@@@


Expected Results:

You shouldn't be limited in where you can place a static 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 Nov 30 09:29:05 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 09:29:05 -0600 (CST)
Subject: [LLVMbugs] [Bug 8708] New: Clang rejects a number of explicit
	specializations
Message-ID: <bug-8708-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8708

           Summary: Clang rejects a number of explicit specializations
           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 web.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I've tried to read through n3126's 14.7.3 explicit specialization subsection
and with the help of the GCC and Comeau-Online compilers came up with these
tests:

--------------------------------

template<typename T> struct A { 
  template<typename U> struct B {
    // #2
    void f();     
  }; 
};  

// #A specialize the member template for 
// implicit instantiation of A<int>,
// leaving the member template "unspecialized"
// (14.7.3/16). Specialization uses the syntax
// for explicit specialization (14.7.3/14)
template<> template<typename U> 
struct A<int>::B {
  // #1
  void g();
};  

// #1 define its function g. There is an enclosing
// class template, so we write template<> for each 
// specialized template (14.7.3/15).
template<> template<typename U>
void A<int>::B<U>::g() { }

// #2 define the unspecialized member template's
// f
template<typename T> template<typename U>
void A<T>::B<U>::f() { }


// specialize the member template again, now
// specializing the member too. This specializes
// #A
template<> template<>
struct A<int>::B<int> { 
  // #3
  void h();
};

// defines #3. There is no enclosing class template, so
// we write no "template<>".
void A<int>::B<int>::h() { }

int main() { 
  // calls #1
  A<int>::B<float> a; a.g(); 

  // calls #2
  A<float>::B<int> b; b.f();

  // calls #3
  A<int>::B<int> c; c.h();
}

-----------------------------

Clang gives the following diagnostics:

main1.cpp:23:20: error: specialization of member 'A<int>::B::g' does not
specialize an instantiated member
void A<int>::B<U>::g() { }
                   ^
main1.cpp:16:8: note: attempt to specialize declaration here                    
  void g();
       ^
main1.cpp:42:6: error: template specialization requires 'template<>'            
void A<int>::B<int>::h() { }
     ^~~~~~~~~~~~~~~~
template<>                                                                      
main1.cpp:42:22: error: specialization of member 'A<int>::B<int>::h' does not
specialize an instantiated member                                       
void A<int>::B<int>::h() { }
                     ^
main1.cpp:37:8: note: attempt to specialize declaration here                    
  void h();
       ^
main1.cpp:52:23: error: call to member function 'h' is ambiguous                
  A<int>::B<int> c; c.h();
                    ~~^
main1.cpp:37:8: note: candidate function                                        
  void h();
       ^
main1.cpp:42:22: note: candidate function                                       
void A<int>::B<int>::h() { }
                     ^
4 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  Tue Nov 30 09:38:07 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 09:38:07 -0600 (CST)
Subject: [LLVMbugs] [Bug 8704] LLVM/Clang unexpectedly generates ivar for
 readonly properties
In-Reply-To: <bug-8704-206@http.llvm.org/bugs/>
References: <bug-8704-206@http.llvm.org/bugs/>
Message-ID: <20101130153807.8E88E2A6C130@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8704

Fariborz Jahanian <fjahanian at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Fariborz Jahanian <fjahanian at apple.com> 2010-11-30 09:38:07 CST ---
1.6 was experimental and not production quality. This bug has been fixed
(non-reproducible)
in clang 2.0. Please use the latest current from latest DP; thanks.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 12:37:03 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 12:37:03 -0600 (CST)
Subject: [LLVMbugs] [Bug 8709] New: -mmacosx-version-min improperly added to
 options when build isn't on Darwin
Message-ID: <bug-8709-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8709

           Summary: -mmacosx-version-min improperly added to options when
                    build isn't on Darwin
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvmbugzilla-75 at apokalypsesoftware.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5840)
 --> (http://llvm.org/bugs/attachment.cgi?id=5840)
patch to relocate target=darwin check within preceding host=darwin check

A check is made if the target for the built toolchain is darwin, and a
darwin-specific option is added.

This option isn't applicable, however, when the toolchain is being built, or
hosted, on another platform (eg, linux).

I've attached a patch that relocates this check within another check that the
host platform is darwin.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 14:23:50 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 14:23:50 -0600 (CST)
Subject: [LLVMbugs] [Bug 8679] -O1 compilation uses all memory and fails on
 32- and 64-bit Ubuntu 10.10 installs
In-Reply-To: <bug-8679-206@http.llvm.org/bugs/>
References: <bug-8679-206@http.llvm.org/bugs/>
Message-ID: <20101130202350.1E2762A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8679

Dale Johannesen <dalej at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Dale Johannesen <dalej at apple.com> 2010-11-30 14:23:49 CST ---
Fixed in 120457.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 14:52:06 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 14:52:06 -0600 (CST)
Subject: [LLVMbugs] [Bug 6550] linker error for std::istream::seekg
In-Reply-To: <bug-6550-206@http.llvm.org/bugs/>
References: <bug-6550-206@http.llvm.org/bugs/>
Message-ID: <20101130205206.A87722A6C131@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6550

Ettl Martin <ettl.martin at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |ettl.martin at gmx.de
         Resolution|FIXED                       |

--- Comment #2 from Ettl Martin <ettl.martin at gmx.de> 2010-11-30 14:52:05 CST ---
$ clang++ -v 
clang version 2.8 (branches/release_28)
Target: i386-pc-linux-gnu
Thread model: posix


This bug is still present:

compiling the test.cc file gives:

$ clang++ test.cc 
/tmp/cc-fxU0jW.o: In function `main':
test.cc:(.text+0x9c): undefined reference to `std::basic_istream<char,
std::char_traits<char> >::seekg(long, std::_Ios_Seekdir)'
collect2: ld returned 1 exit status

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 15:03:34 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 15:03:34 -0600 (CST)
Subject: [LLVMbugs] [Bug 6550] linker error for std::istream::seekg
In-Reply-To: <bug-6550-206@http.llvm.org/bugs/>
References: <bug-6550-206@http.llvm.org/bugs/>
Message-ID: <20101130210334.217482A6C131@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6550

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2010-11-30 15:03:33 CST ---
Clang 2.8 is fairly old by now, and this appears to be working fine with
top-of-tree Clang. If it's not working for you with top-of-tree Clang, please
re-open and provide preprocessed output + more information about the version of
libstdc++ you are using.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 15:43:23 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 15:43:23 -0600 (CST)
Subject: [LLVMbugs] [Bug 6550] linker error for std::istream::seekg
In-Reply-To: <bug-6550-206@http.llvm.org/bugs/>
References: <bug-6550-206@http.llvm.org/bugs/>
Message-ID: <20101130214324.018C82A6C130@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6550

Tim <tim.dawborn at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #6 from Tim <tim.dawborn at gmail.com> 2010-11-30 15:43:23 CST ---
I can confirm this is fixed in trunk.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 15:57:33 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 15:57:33 -0600 (CST)
Subject: [LLVMbugs] [Bug 8710] New: Optimizer moves a @__cxx_global_var_init
 into a constant expression, causing as to fail
Message-ID: <bug-8710-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8710

           Summary: Optimizer moves a @__cxx_global_var_init into a
                    constant expression, causing as to fail
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: d235j.1 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When opt is used on the .bc output produced by clang++ from the attached .ii
file, the assembler fails with the following error:

fatal error: error in backend: expected relocatable expression

If no optimization is applied, the bug does not happen.

This code is to be compiled as 64-bit. I'm told this bug is similar to
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-October/035746.html .

The .ii file is attached.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 16:14:56 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 16:14:56 -0600 (CST)
Subject: [LLVMbugs] [Bug 8711] New: infinite loop in MCAsmLayout::EnsureValid
Message-ID: <bug-8711-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8711

           Summary: infinite loop in MCAsmLayout::EnsureValid
           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


Hello,

when I compile a source file with clang++, the compilation never stops.
Attaching gdb to clang shows that it is stuck in:
llvm::MCAsmLayout::EnsureValid(llvm::MCFragment const*) const

This is a recent regression (at most 2-3 weeks I guess).

I am not sure what the right way is to proceed. I can provide you with a
preprocessed source file that exhibits this behavior, but it is likely to be
around 1 million lines. It is much harder to produce a reduced testcase than
with a crash.

Since the function has Asm in its name, let me mention this is an x86_64 and I
don't specify any arch/tune.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 17:05:53 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 17:05:53 -0600 (CST)
Subject: [LLVMbugs] [Bug 6043] [DSE] Large store doesn't make small stores
	dead
In-Reply-To: <bug-6043-206@http.llvm.org/bugs/>
References: <bug-6043-206@http.llvm.org/bugs/>
Message-ID: <20101130230553.39D442A6C130@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6043

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Chris Lattner <clattner at apple.com> 2010-11-30 17:05:52 CST ---
This is now implemented in r120485, optimizing the testcase down to a single
store.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 17:08:32 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 17:08:32 -0600 (CST)
Subject: [LLVMbugs] [Bug 8707] Blocks cannot contain static variables when
 compiled with clang, works with LLVM-GCC 4.2
In-Reply-To: <bug-8707-206@http.llvm.org/bugs/>
References: <bug-8707-206@http.llvm.org/bugs/>
Message-ID: <20101130230832.1BEEB2A6C130@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8707

Fariborz Jahanian <fjahanian at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Fariborz Jahanian <fjahanian at apple.com> 2010-11-30 17:08:31 CST ---
This is fixed in TOT:
http://llvm.org/viewvc/llvm-project?view=rev&revision=120486

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 17:22:58 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 17:22:58 -0600 (CST)
Subject: [LLVMbugs] [Bug 8657] DSE doesn't remove know that
 complete-object-stores kill variable stores into object
In-Reply-To: <bug-8657-206@http.llvm.org/bugs/>
References: <bug-8657-206@http.llvm.org/bugs/>
Message-ID: <20101130232258.CE6C12A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8657

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |
            Summary|DSE doesn't remove small    |DSE doesn't remove know
                   |stores overwritten by later |that complete-object-stores
                   |large ones                  |kill variable stores into
                   |                            |object

--- Comment #5 from Chris Lattner <clattner at apple.com> 2010-11-30 17:22:58 CST ---
Reopening this to track the variable case.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 17:32:01 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 17:32:01 -0600 (CST)
Subject: [LLVMbugs] [Bug 8706] Assertion `Ty->isSized() && "Cannot
 getTypeInfo() on a type that is unsized!"' failed.
In-Reply-To: <bug-8706-206@http.llvm.org/bugs/>
References: <bug-8706-206@http.llvm.org/bugs/>
Message-ID: <20101130233201.0DD842A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8706

John McCall <rjmccall at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from John McCall <rjmccall at apple.com> 2010-11-30 17:32:00 CST ---
I'm not sure why my commit exposed this, but I've fixed the underlying problem
in r120491.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 17:45:36 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 17:45:36 -0600 (CST)
Subject: [LLVMbugs] [Bug 8657] DSE doesn't remove know that
 complete-object-stores kill variable stores into object
In-Reply-To: <bug-8657-206@http.llvm.org/bugs/>
References: <bug-8657-206@http.llvm.org/bugs/>
Message-ID: <20101130234536.F0EBD2A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8657

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Chris Lattner <clattner at apple.com> 2010-11-30 17:45:36 CST ---
Implemented in r120498.  LLVM now optimizes the testcase to a single store when
it's a C++ file or built with -fno-common.

If GCC optimizes this in the C case with -fcommon, you should file a bug
against GCC.  "i" may not be in the range of 0..3 if another translation unit
defines a larger "u" with a strong definition, and thus the optimization is
invalid with -fcommon.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Nov 30 19:36:52 2010
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 30 Nov 2010 19:36:52 -0600 (CST)
Subject: [LLVMbugs] [Bug 7137] [DSE] Dead store elimination removes only one
 store per pass in simple case
In-Reply-To: <bug-7137-206@http.llvm.org/bugs/>
References: <bug-7137-206@http.llvm.org/bugs/>
Message-ID: <20101201013652.8A5E82A6C130@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=7137

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Chris Lattner <clattner at apple.com> 2010-11-30 19:36:52 CST ---
Yep, DSE is now doing the right thing here.  The malloc/free not getting zapped
is because instcombine doesn't run after DSE.  That issue is tracked in PR2338

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.