From bugzilla-daemon at llvm.org  Sun May  1 07:36:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  1 May 2011 07:36:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9822] New: MC produces Undefined symbol while gnu
 as produces nothing
Message-ID: <bug-9822-206@http.llvm.org/bugs/>

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

           Summary: MC produces Undefined symbol while gnu as produces
                    nothing
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


witten webcamd-0.1.26# clang -c linux.clang.s -o l.o && nm l.o
00000090 T linux_exit
         U linux_exit_mod
00000020 T linux_init
         U linux_init_mod
00000010 t linux_module_exit_start
00000000 d linux_module_exit_start_p
00000000 t linux_module_init_start
00000000 d linux_module_init_start_p
         U thread_init

witten webcamd-0.1.26# as linux.clang.s -o l.o && nm l.o
00000080 T linux_exit
00000020 T linux_init
00000010 t linux_module_exit_start
00000000 d linux_module_exit_start_p
00000000 t linux_module_init_start
00000000 d linux_module_init_start_p
         U thread_init

note the linux_{exit|init}_mod undefined symbol produced by MC.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  1 15:27:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  1 May 2011 15:27:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9823] New: Assertion `SegStart >= Intf.last() &&
 "Couldn't avoid interference"' failed.
Message-ID: <bug-9823-206@http.llvm.org/bugs/>

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

           Summary: Assertion `SegStart >= Intf.last() && "Couldn't avoid
                    interference"' 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/tmp024$ clang -c -O -w small.c
clang: RegAllocGreedy.cpp:799:
void<unnamed>::RAGreedy::splitAroundRegion(llvm::LiveInterval&,
<unnamed>::RAGreedy::GlobalSplitCandidate&,
llvm::SmallVectorImpl<llvm::LiveInterval*>&): Assertion `SegStart >=
Intf.last() && "Couldn't avoid interference"' failed.
0  clang 0x09643c58
Stack dump:
0.    Program arguments:
/mnt/z/z/compiler-install/llvm-gcc-r130662-install/bin/clang -cc1 -triple
i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -target-linker-version 2.20.51 -momit-leaf-frame-pointer
-resource-dir
/mnt/z/z/compiler-install/llvm-gcc-r130662-install/bin/../lib/clang/3.0 -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.    Code generation
3.    Running pass 'Function Pass Manager' on module 'small.c'.
4.    Running pass 'Greedy Register Allocator' on function '@func_64'
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/tmp024$ clang -v

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

regehr at home:~/volatile/bugs/tmp024$ cat small.c


int safe_4 (int si1, int si2)
{
  return si2 && (1 / si1) ? si1 : si2;
}

int safe_6 (char si1, char si2)
{
  return si2 == 0 || si1 && si2 == 1 ? si1 : 1;
}

int safe_26 (int si1, int si2)
{
  return si2 ? si1 : (si1 / si2);
}

int safe_55 (int ui1, int ui2)
{
  return ui1;
}

int g_3;
int g_301;
int g_382;

int func_64 (int p_65, int p_67)
{
  int l_79;
  int l_357;
  for (l_357 = 0; l_357 <= 0; l_357 = 1)
    if (p_67)
      break;
  for (l_79 = 0; l_79 <= 0; l_79 += 1)
    if (safe_6
    (safe_26 (safe_55 (g_301 >= 1, 0), safe_4 (g_3, p_65)), l_357)
    || g_301)
      for (; g_382; g_382 -= 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  Sun May  1 16:48:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  1 May 2011 16:48:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9748] [x86-32 ELF PIC,
 GreedyRA] UNREACHABLE executed at X86MCInstLower.cpp:140!
In-Reply-To: <bug-9748-206@http.llvm.org/bugs/>
References: <bug-9748-206@http.llvm.org/bugs/>
Message-ID: <20110501214848.B98A12A6C13C@llvm.org>

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

Dimitry Andric <dimitry at andric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |dimitry at andric.com
         Resolution|FIXED                       |

--- Comment #9 from Dimitry Andric <dimitry at andric.com> 2011-05-01 16:48:46 CDT ---
I have still encountered this while self-hosting r130606 on FreeBSD
i386.  A reduced testcase (from LoopUnswitch.cpp) is attached.

Use:

clang -cc1 -triple i386-unknown-freebsd9.0 -S -mdisable-fp-elim -O2
pr9748-2.cpp

to trigger "Unknown target flag on GV operand".

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

From bugzilla-daemon at llvm.org  Sun May  1 17:00:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  1 May 2011 17:00:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9748] [x86-32 ELF PIC,
 GreedyRA] UNREACHABLE executed at X86MCInstLower.cpp:140!
In-Reply-To: <bug-9748-206@http.llvm.org/bugs/>
References: <bug-9748-206@http.llvm.org/bugs/>
Message-ID: <20110501220016.C4AAA2A6C13B@llvm.org>

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

Dimitry Andric <dimitry at andric.com> changed:

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

--- Comment #11 from Dimitry Andric <dimitry at andric.com> 2011-05-01 17:00:15 CDT ---
Argh, sorry for the pollution, I should refresh PRs before submitting
stuff. :)  I just tried it again with r130666, and now it works.

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

From bugzilla-daemon at llvm.org  Sun May  1 20:59:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  1 May 2011 20:59:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9824] New: add -Wunused-but-set-variable
Message-ID: <bug-9824-206@http.llvm.org/bugs/>

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

           Summary: add -Wunused-but-set-variable
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


GCC 4.6 has a nice warning part of -Wall which warns on variables that are used
by being set, but never read or have their address taken. We should add
-Wunused-but-set-variable to clang.

Here's a few examples of how the warning behaves in GCC:

  void test1() {
    int i = 0;  // -Wunused-but-set-variable warning
    i = 1;
  }

  void test2() {
    int i = 0;  // no warning
    i = 1;
    &i;  // -Wunused-value warning
  }

  void test3() {
    int i = 1;  // -Wunused-variable warning, not -Wunused-but-set-variable.
  }

  void use(int);
  void test4() {
    int i = 0;  // no warning
    use1(i);
  }

which seems eminently sane to me.

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

From bugzilla-daemon at llvm.org  Mon May  2 00:30:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 00:30:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9823] Assertion `SegStart >= Intf.last() &&
 "Couldn't avoid interference"' failed.
In-Reply-To: <bug-9823-206@http.llvm.org/bugs/>
References: <bug-9823-206@http.llvm.org/bugs/>
Message-ID: <20110502053040.6E9B52A6C139@llvm.org>

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

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

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

--- Comment #2 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-02 00:30:40 CDT ---
Fixed in r130687.

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

From bugzilla-daemon at llvm.org  Mon May  2 09:09:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 09:09:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9825] New: Need both -fno-omit-frame-pointer and
 -mno-omit-leaf-frame-pointer to get a fp on linux on a leaf function
Message-ID: <bug-9825-206@http.llvm.org/bugs/>

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

           Summary: Need both -fno-omit-frame-pointer and
                    -mno-omit-leaf-frame-pointer to get a fp on linux on a
                    leaf function
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ cat test.c
int f() {
  return 42;
}
$ gcc -S /home/espindola/llvm/test.c -Os -fno-omit-frame-pointer -o - | grep
rbp
    pushq    %rbp
    movq    %rsp, %rbp
$ ./bin/clang -S /home/espindola/llvm/test.c -Os -fno-omit-frame-pointer -o - |
grep rbp
$ ./bin/clang -S /home/espindola/llvm/test.c -Os -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -o - | grep rbp
    pushq    %rbp
    movq    %rsp, %rbp
    popq    %rbp

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

From bugzilla-daemon at llvm.org  Mon May  2 09:16:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 09:16:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9826] New: [MC] Should use symbolic register names
 in the .cfi_* directives
Message-ID: <bug-9826-206@http.llvm.org/bugs/>

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

           Summary: [MC] Should use symbolic register names in the .cfi_*
                    directives
           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


Instead of printing:

f:
    .cfi_startproc
    .cfi_offset 6, -16
    .cfi_endproc

We could print

f:
    .cfi_startproc
    .cfi_offset %rbp, -16
    .cfi_endproc

Both produce bit identical results, but the second one is more readable. In the
interest of efficiency, the MCStreamer should probably stay the same: It is
given a register dwarf num. This means we need a dwarf num -> name mapping. We
can probably tblgen 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 May  2 10:15:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 10:15:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9827] New: some mess in the options passed to Clang
 during the invocation through llvmc
Message-ID: <bug-9827-206@http.llvm.org/bugs/>

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

           Summary: some mess in the options passed to Clang during the
                    invocation through llvmc
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: codacat at ya.ru
                CC: llvmbugs at cs.uiuc.edu


I am running ArchLinux with following clang and llvm versions:

$ clang -v
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ llvmc --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.9
  Optimized build.
  Built Apr 11 2011 (14:36:05).
  Host: x86_64-unknown-linux-gnu
  Host CPU: amdfam10

  Registered Targets:
    (none)

When i try to compile simple hello-world program with command line, i get an
error report:

$ llvmc -clang hello.c
clang -x c hello.c -emit-llvm-bc -o /tmp/llvm_09ut0R/hello.bc 
clang: warning: argument unused during compilation: '-e mit-llvm-bc'
llc -O2 /tmp/llvm_09ut0R/hello.bc -o /tmp/llvm_09ut0R/hello.s 
llc: /tmp/llvm_09ut0R/hello.bc:1:1: error: expected top-level entity
ELF> ... <a lot of unprintable characters>

So it seems, that wrong option is passed to the clang front-end, and it
translates source to the ELF object file instead of LLVM bitcode.

When i translate hello.c to the bitcode manually with:

$ clang -c -emit-llvm hello.c -o hello.bc

And then use llvmc with the bitcode:

$ llvmc -v -clang hello.bc -o hello
llc -O2 hello.bc -o /tmp/llvm_ZEvkLH/hello.s 
as /tmp/llvm_ZEvkLH/hello.s -o /tmp/llvm_ZEvkLH/hello.o 
llvm-ld -native -disable-internalize /tmp/llvm_ZEvkLH/hello.o -o hello

everything works 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  Mon May  2 10:40:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 10:40:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9828] New: False positive for null function pointer
 call following assert()
Message-ID: <bug-9828-206@http.llvm.org/bugs/>

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

           Summary: False positive for null function pointer call
                    following assert()
           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: hyrum at hyrumwright.org
                CC: llvmbugs at cs.uiuc.edu


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

I'm using the analyzer on the following test case:
[[[
#include <stdlib.h>

typedef int (*foo_editor_cb_complete_t)(void *baton);

int
foo_editor_complete(foo_editor_cb_complete_t func)
{
  assert(func != NULL);
  return func(NULL);
}
]]]

The results are:
[[[
cca-bug1.c:9:10: warning: Called function pointer is null (null dereference)
  return func(NULL);
         ^
1 warning generated.
scan-build: 1 bugs found.
]]]

I believe the above to be a false positive.  The assert() on line 8 should
eliminate any concerns that the called function pointer is NULL.  However, the
analyzer?misses this fact and generates the bug all the same.

I'm using the checker-256 release on Mac OS X.

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

From bugzilla-daemon at llvm.org  Mon May  2 10:47:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 10:47:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9806] strncpy and strncat checkers assert when
 bounds argument is undefined.
In-Reply-To: <bug-9806-206@http.llvm.org/bugs/>
References: <bug-9806-206@http.llvm.org/bugs/>
Message-ID: <20110502154706.C98282A6C124@llvm.org>

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

Lenny Maiorani <lenny at colorado.edu> changed:

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

--- Comment #2 from Lenny Maiorani <lenny at colorado.edu> 2011-05-02 10:47:05 CDT ---
Patch submitted in r130422 fixed the assert.

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

From bugzilla-daemon at llvm.org  Mon May  2 11:10:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 11:10:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9829] New: undefined reference to __mingw_vprintf
 when linking to libLLVMCore.a
Message-ID: <bug-9829-206@http.llvm.org/bugs/>

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

           Summary: undefined reference to __mingw_vprintf when linking to
                    libLLVMCore.a
           Product: libraries
           Version: 2.9
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dash4893h4932 at abv.bg
                CC: llvmbugs at cs.uiuc.edu


hello,

on winxp-sp2-x86 installing the following official packages in /llvm/:

llvm-gcc4.2-2.9-x86-mingw32.tar.bz2
llvm-2.9-mingw32-i386.tar.bz2
binutils-2.20-1-mingw32-bin.tar.gz

compiling example at:

http://gnuu.org/2009/09/18/writing-your-own-toy-compiler/all/1/

constructing and adjusting cmd line:

perl llvm-config --libs core jit native --cxxflags --ldflags

llvm-g++ *.cpp -o a.exe -I/llvm/include -DNDEBUG -D__NO_CTYPE_INLINE
-D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2
-fomit-frame-pointer -fno-exceptions -Woverloaded-virtual -Wcast-qual
-L/llvm/lib -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen
-lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86AsmPrinter
-lLLVMX86Utils -lLLVMX86Info -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen
-lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa
-lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport
-lLLVMSystemZCodeGen -lLLVMSystemZInfo -lpsapi -limagehlp -lm


results in:

Warning: .drectve `-aligncomm:___CTOR_LIST__,2 ' unrecognized
Warning: .drectve `-aligncomm:___DTOR_LIST__,2' unrecognized
/llvm/lib/libLLVMCore.a(PassManager.o)(.text+0x13):PassManager.cpp: undefined
reference to `__mingw_vprintf'
/llvm/lib/libLLVMSupport.a(Signals.o)(.text+0x1b):Signals.cpp: undefined
reference to `__mingw_vfprintf'
/llvm/lib/libLLVMSupport.a(Path.o)(.text+0x1b):Path.cpp: undefined reference to
`__mingw_vsprintf'
collect2: ld returned 1 exit status

---

collect2 suggest that the mingw versions of these functions were linked.
'grep' does not return any files containing these symbols in llvm/lib. the
closest possible location is /llvm/lib/libmingwex.a, which contains symbols
like __mingw_vsnprintf, __mingw_snprintf.
a solution is to define the symbols manually e.g. blank functions in a object
file.

D.K.

P.S.1:
i've sent an email yesterday to the list directly, but using the BZ system
might be better...i was also able to recompiled the support / core libraries
from the 2.9 source with mingw-gcc-4.4.1, but got a lot of SJLJ errors instead
of the '__mingw_*' when linking.

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

From bugzilla-daemon at llvm.org  Mon May  2 11:15:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 11:15:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9830] New: Clang doesn't like ZeroMemory,
	causes crash in Wine
Message-ID: <bug-9830-206@http.llvm.org/bugs/>

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

           Summary: Clang doesn't like ZeroMemory, causes crash in Wine
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: austinenglish at gmail.com
                CC: llvmbugs at cs.uiuc.edu


See: http://bugs.winehq.org/show_bug.cgi?id=26754

likely a regression, though haven't retested with an older Clang yet. Compiling
Wine with clang from trunk (clang version 3.0 (trunk 130453)), and running
wine's builtin 'regedit' program causes a crash. The crash can be avoided by
not using ZeroMemory, or compiling the particular file with gcc instead of
clang.

Occurs with/without integrated assembler.

clang -E -I. -I. -I../../include -I../../include  -D__WINESRC__ -D_COMCTL32_
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings
-Wpointer-arith  -std=gnu89 -g -O0 -o imagelist.i imagelist.c

preprocessed .i file attached (for Clang and gcc).attached

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

From bugzilla-daemon at llvm.org  Mon May  2 12:59:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 12:59:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9828] False positive for null function pointer call
 following assert()
In-Reply-To: <bug-9828-206@http.llvm.org/bugs/>
References: <bug-9828-206@http.llvm.org/bugs/>
Message-ID: <20110502175951.C59342A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #1 from Ted Kremenek <kremenek at apple.com> 2011-05-02 12:59:51 CDT ---
Looks like 'assert' is not defined, and the compiler is treating it as an
undeclared function.  This is the warning I see from clang (the compiler):


ca-bug1.c:8:3: warning: implicit declaration of function 'assert' is invalid in
C99 [-Wimplicit-function-declaration]
  assert(func != NULL);
  ^


This means your assert() isn't actually doing what you think it is.

Try:

#include <assert.h>

On the Mac, that causes 'assert' to be defined correctly and the false path
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  Mon May  2 13:52:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 13:52:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9579] A bug in InstructionSimplify.cpp
In-Reply-To: <bug-9579-206@http.llvm.org/bugs/>
References: <bug-9579-206@http.llvm.org/bugs/>
Message-ID: <20110502185232.1A2022A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2011-05-02 13:52:31 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110502/120304.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 May  2 19:19:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  2 May 2011 19:19:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9831] New: Assertion `(*I)->hasAtLeastOneValue() &&
 "Split interval has no value"' failed.
Message-ID: <bug-9831-206@http.llvm.org/bugs/>

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

           Summary: Assertion `(*I)->hasAtLeastOneValue() && "Split
                    interval has no value"' 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/tmp026$ clang -O3 -w small.c
clang: SplitKit.cpp:993: void
llvm::SplitEditor::finish(llvm::SmallVectorImpl<unsigned int>*): Assertion
`(*I)->hasAtLeastOneValue() && "Split interval has no value"' failed.
0  clang 0x09646098
Stack dump:
0.    Program arguments:
/mnt/z/z/compiler-install/llvm-gcc-r130740-install/bin/clang -cc1 -triple
i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -target-linker-version 2.20.51 -momit-leaf-frame-pointer
-resource-dir
/mnt/z/z/compiler-install/llvm-gcc-r130740-install/bin/../lib/clang/3.0 -O3 -w
-ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-CZbR9X.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 'Greedy Register Allocator' on function '@func_47'
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/tmp026$ clang -v
clang version 3.0 (trunk 130740)
Target: i386-pc-linux-gnu
Thread model: posix
regehr at home:~/volatile/bugs/tmp026$ cat small.c
int
safe_6 (char si1, int si2)
{
  return si2 == 0 || si1 && si2 == 1 ? 0 : (si1 / 0);
}

int
safe_43 (int ui1, int ui2)
{
  return ui1;
}

int
safe_52 (short ui1, int ui2)
{
  return ui1;
}

struct S0
{
  int f3:0 ? 0 : 24;
  int f4:1;
  int f5;
int f6:1};
int g_77;
int g_207[0][0][1] = {
};

struct S0 *g_220;
int g_229;
struct S0 **g_274;
int
func_47 (int *p_48, int p_51)
{
  for (0; 1; 0)
    {
      int *l_238 = 1;
      struct S0 l_240[1] = {
      };
      struct S0 l_244 = {
    0
      };
      struct S0 l_252 = {
    0
      };
      if (*l_238)
    {
      *g_220 = l_240[0];
      l_244 = l_240[0];
      for (g_229 = 0; g_229 <= 2; g_229 += 1)
        l_244.f3 &= g_207[0][g_77][p_51] = safe_6 (l_244.f6, p_51) != 1;
    }
      if (l_244.f3)
    {
      l_252.f4 = safe_43 (l_244.f6, 1);
      for (0; l_252.f5 <= 0; l_252.f5 = safe_52 (l_252.f5, 1))
        {
        }
    }
      *g_274 = &l_240[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 May  3 00:14:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  3 May 2011 00:14:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9829] undefined reference to __mingw_vprintf when
 linking to libLLVMCore.a
In-Reply-To: <bug-9829-206@http.llvm.org/bugs/>
References: <bug-9829-206@http.llvm.org/bugs/>
Message-ID: <20110503051434.768E82A6C12C@llvm.org>

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

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

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

--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru> 2011-05-03 00:14:33 CDT ---
mingw libraries depends heavily on the version of gcc used for compilation and
the version of mingw runtime. If you're seeing the problems like this, please
consider recompiling stuff from the sources. In any case, this is the best
thing when you're going to do some development with LLVM.

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

From bugzilla-daemon at llvm.org  Tue May  3 02:08:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  3 May 2011 02:08:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9832] New: [MC] Thumb/Thumb-2 are not handled
 properly in ARM ELF
Message-ID: <bug-9832-206@http.llvm.org/bugs/>

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

           Summary: [MC] Thumb/Thumb-2 are not handled properly in ARM ELF
           Product: new-bugs
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: koansin.tan at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6525)
 --> (http://llvm.org/bugs/attachment.cgi?id=6525)
a quick patch to make clang generate thumb code in ARM ELF.

We are trying to use clang as a drop-in replacement for the gcc come with
Android NDK. I found that MC/ELF doesn't not handle Thumb functions properly,
e.g., bit 0 of the function name in the .symtab is not set to 1, and some thumb
instructions are not generated correctly, e.g., tBLXr doesn't read it operand.

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

From bugzilla-daemon at llvm.org  Tue May  3 12:00:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  3 May 2011 12:00:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9833] New: broken lit substitutions
Message-ID: <bug-9833-206@http.llvm.org/bugs/>

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

           Summary: broken lit substitutions
           Product: Test Suite
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: lit
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bob.wilson at apple.com
                CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org


If I build llvm+clang in a directory ending with "-clang", e.g.,
"objdir-clang", the lit tool substitutes the full path of clang for that
"clang" suffix.  This happens for every instance of "clang" is a command, not
just for the program name.  For example, I see include paths like:

    -I
/Volumes/LocalHD/bwilson/llvm/objdir-/Volumes/LocalHD/bwilson/llvm/objdir-clang/Debug+Asserts/bin/clang/include

even though the site.exp file shows:

    -I /Volumes/LocalHD/bwilson/llvm/objdir-clang/include

I think the problem is here:

    # Extract the tool name from the pattern.  This relies on the tool
    # name being surrounded by \b word match operators.  If the
    # pattern starts with "| ", include it in the string to be
    # substituted.
    substitution = re.sub(r"^(\\)?((\| )?)\W+b([0-9A-Za-z-_]+)\\b\W*$",
                          r"\2" + llvm_tools_dir + "/" + r"\4",
                          pattern)

but my Python skills are not great and that's a big ugly regexp.

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

From bugzilla-daemon at llvm.org  Tue May  3 13:19:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  3 May 2011 13:19:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9834] New: clang accepts 'friend' at ill-formed
 positions in the decl-specifier-seq
Message-ID: <bug-9834-206@http.llvm.org/bugs/>

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

           Summary: clang accepts 'friend' at ill-formed positions in the
                    decl-specifier-seq
           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


clang accepts this:

  struct S {
    class T friend;
    unsigned friend char;
  };

Both of these are illegal by [class.friend]p3, which requires the 'friend'
decl-specifier to be the first in the decl-specifier-seq for non-function
declarations.

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

From bugzilla-daemon at llvm.org  Tue May  3 15:42:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  3 May 2011 15:42:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9831] Assertion `(*I)->hasAtLeastOneValue() &&
 "Split interval has no value"' failed.
In-Reply-To: <bug-9831-206@http.llvm.org/bugs/>
References: <bug-9831-206@http.llvm.org/bugs/>
Message-ID: <20110503204242.832212A6C12D@llvm.org>

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

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

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

--- Comment #2 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-03 15:42:41 CDT ---
Fixed in r130787, thanks John!

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

From bugzilla-daemon at llvm.org  Tue May  3 21:05:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  3 May 2011 21:05:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9835] New: Clang cannot decay [] to * automatically
Message-ID: <bug-9835-206@http.llvm.org/bugs/>

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

           Summary: Clang cannot decay [] to * automatically
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nowar100 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When I compile skia source code, it complains:

src/src/core/SkBitmap.cpp:1047:57: error: restrict requires a pointer or
reference ('uint8_t' (aka 'unsigned char') is invalid)
static bool GetBitmapAlpha(const SkBitmap& src, uint8_t __restrict__ alpha[],
                                                ~~~~~~~~^~~~~~~~~~~~

We see that parameter alpha could be decay to a pointer. But Clang doesn't
know.
Is this a bug?


P.S.
I don't think I could upload the SkBitmap.cpp.  It is from
http://www.spec.org/.

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

From bugzilla-daemon at llvm.org  Wed May  4 01:16:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 01:16:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9836] New: Strange "read-only variable is not
 assignable" error with restrict
Message-ID: <bug-9836-206@http.llvm.org/bugs/>

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

           Summary: Strange "read-only variable is not assignable" error
                    with restrict
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Testcase:
void a(int alpha[restrict]) { alpha = 0;}

Output:
<stdin>:1:37: error: read-only variable is not assignable
void a(int alpha[restrict]) { alpha = 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 May  4 01:27:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 01:27:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9835] Clang cannot decay [] to * automatically
In-Reply-To: <bug-9835-206@http.llvm.org/bugs/>
References: <bug-9835-206@http.llvm.org/bugs/>
Message-ID: <20110504062702.3B4A62A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-04 01:27:01 CDT ---
Looks like a combination of a gcc bug and a bug in the source code; take the
following:::
typedef int x;
void GetBitmapAlpha(int __restrict__ alpha[]);
void GetBitmapAlpha(x __restrict__ alpha[]);

gcc in C mode, and clang, reject both versions.  gcc in C++ mode, for some
strange reason, accepts the second version.

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

From bugzilla-daemon at llvm.org  Wed May  4 04:14:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 04:14:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9837] New: Inline assembler dies on WindowMaker
 source file (wrlib/x86_specific.c)
Message-ID: <bug-9837-206@http.llvm.org/bugs/>

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

           Summary: Inline assembler dies on WindowMaker source file
                    (wrlib/x86_specific.c)
           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


Created an attachment (id=6526)
 --> (http://llvm.org/bugs/attachment.cgi?id=6526)
Problematic inline assembly from WindowMaker

Clang's inline assembler, as of r130836, dies on this file, when
compiling it for i386:

http://hg.windowmaker.info/wmaker/file/7accebd7c65b/wrlib/x86_specific.c

with the following error:

==================================================
fatal error: error in backend: Ran out of registers during register allocation!
Please check your inline asm statement for invalid constraints:
INLINEASM <es:pushl %ebx
        movl  $7, %eax
        movl  $8, %ebx
        movl  $9, %ecx
        movw  %ax, $16
        movw  %bx, $17
        movw  %cx, $18
        movw  $$0,  $19
        movq  $16, %mm6
        movl $$0x00040004, $16
        movl $$0x00040004, $18
        movq $16, %mm7
        movl $$0x00070007, $16
        movl $$0x00070007, $18
        movq $16, %mm5
        movl $$0x00050005, $16
        movl $$0x00050005, $18
        movq $16, %mm4
        movl $$0x00030003, $16
        movl $$0x00030003, $18
        movq $16, %mm3
        movl $0, %esi
.LoopYa:
        movl $13, %eax
        movl %eax, $26
        movl $14, %eax
        decl %eax
        movl %eax, $14
        js .Enda
        andl $$1, %eax
        jz .LoopY_1a
.LoopY_0a:
        movl $2, %ebx
        movl %ebx, $25
        movl $3, %eax
        movl %eax, $24
        jmp .LoopXa
.LoopY_1a:
        movl $3, %ebx
        movl %ebx, $25
        movl $2, %eax
        movl %eax, $24
        .align 16
.LoopXa:
        movq (%ebx), %mm1
        punpcklbw (%esi), %mm0
        psrlw $$8, %mm0
        paddusb %mm1, %mm0
        movq %mm0, $20
        movzwl $20, %ecx
        movl $4, %edi
        leal (%edi, %ecx, 2), %eax
        movw (%eax), %dx
        movw %dx, $16
        movzwl $21, %ecx
        movl $5, %edi
        leal (%edi, %ecx, 2), %eax
        movw (%eax), %dx
        movw %dx, $17
        movzwl $22, %ecx
        movl $6, %edi
        leal (%edi, %ecx, 2), %eax
        movw (%eax), %dx
        movw %dx, $18
        movw $$0, $19
        movq $16, %mm1
        pmullw %mm6, %mm1
        psubsw %mm1, %mm0
        movl $25, %ebx
        movq %mm0, %mm1
        pmullw %mm5, %mm1
        psrlw %mm7, %mm1
        paddw 8(%ebx), %mm1
        movq %mm1, 8(%ebx)
        movl $24, %ebx
        movq %mm0, %mm1
        pmullw %mm4, %mm1
        psrlw %mm7, %mm1
        paddw -8(%ebx), %mm1
        movq %mm1, -8(%ebx)
        movq %mm0, %mm1
        pmullw %mm3, %mm1
        psrlw %mm7, %mm1
        paddw 8(%ebx), %mm1
        movq %mm1, (%ebx)
        psrlw %mm7, %mm0
        movq %mm0, 8(%ebx)
        movl $10, %ecx
        movw $16, %ax
        shlw %cl, %ax
        movl $11, %ecx
        movw $17, %bx
        shlw %cl, %bx
        orw %bx, %ax
        movl $12, %ecx
        movw $18, %bx
        shlw %cl, %bx
        orw %bx, %ax
        movl $1, %edx
        movw %ax, (%edx)
        addl $$2, %edx
        movl %edx, $1
        addl $$8, $24
        movl $25, %ebx
        addl $$8, %ebx
        movl %ebx, $25
        addl $$4, %esi
        decl $26
        jnz .LoopXa
        addl $15, %edx
        movl %edx, $1
        jmp .LoopYa
.Enda:
        emms
        popl %ebx
        > [sideeffect], 44, <fi#0>, 1, %noreg, 0, %noreg, 44, <fi#1>, 1,
%noreg, 0, %noreg, 44, <fi#2>, 1, %noreg, 0, %noreg, 44, <fi#3>, 1, %noreg, 0,
%noreg, 44, <fi#4>, 1, %noreg, 0, %noreg, 44, <fi#5>, 1, %noreg, 0, %noreg, 44,
<fi#6>, 1, %noreg, 0, %noreg, 44, <fi#7>, 1, %noreg, 0, %noreg, 44, <fi#8>, 1,
%noreg, 0, %noreg, 44, <fi#9>, 1, %noreg, 0, %noreg, 44, <fi#10>, 1, %noreg, 0,
%noreg, 44, <fi#11>, 1, %noreg, 0, %noreg, 44, <fi#12>, 1, %noreg, 0, %noreg,
44, <fi#13>, 1, %noreg, 0, %noreg, 44, <fi#14>, 1, %noreg, 0, %noreg, 44,
<fi#15>, 1, %noreg, 0, %noreg, 44, %EBX, 1, %noreg, 0, %noreg, 44, %EBP, 1,
%noreg, 0, %noreg, 44, %vreg40, 1, %noreg, 0, %noreg, 44, %vreg36, 1, %noreg,
0, %noreg, 44, %vreg34, 1, %noreg, 0, %noreg, 44, %vreg32, 1, %noreg, 0,
%noreg, 44, %vreg29, 1, %noreg, 0, %noreg, 44, %vreg25, 1, %noreg, 0, %noreg,
44, <fi#18>, 1, %noreg, 0, %noreg, 44, <fi#19>, 1, %noreg, 0, %noreg, 44,
<fi#20>, 1, %noreg, 0, %noreg, 14, %AX<earlyclobber,imp-def>, 14,
%CX<earlyclobber,imp-def>, 14, %DX<earlyclobber,imp-def>, 14,
%SI<earlyclobber,imp-def>, 14, %DI<earlyclobber,imp-def>, 14,
%EFLAGS<earlyclobber,imp-def>, <<badref>>;
GR32:%vreg40,%vreg36,%vreg34,%vreg32,%vreg29,%vreg25
==================================================

The problematic function is x86_mmx_TrueColor_32_to_16(), which I will
add as a testcase (wmasm.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 May  4 05:29:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 05:29:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9838] New: QUEST generated test brocken with
 scalrrepl + instcombine
Message-ID: <bug-9838-206@http.llvm.org/bugs/>

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

           Summary: QUEST generated test brocken with scalrrepl +
                    instcombine
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: quickslyver at free.fr
                CC: llvmbugs at cs.uiuc.edu


using the original quest generated test:
(http://code.google.com/p/quest-tester/)

$ gcc quest-10.c -O0 && ./a.out  #OK
$ gcc quest-10.c -O3 && ./a.out  #OK
$ clang quest-10.c -O0 && ./a.out #OK
$ clang quest-10.c -O1 && ./a.out #FAIL
a.out: quest-10.c:744: double callee_o0f(unsigned long, union ot5, union ot7,
struct ot9, union ot10 *, double *, union ot11, struct ot12 *, struct ot17,
...): Assertion `o69.o13.o8 == o82.o13.o8' failed.


using the reduced version: (quest10-a.c)

$ gcc quest-10a.c -O0 && ./a.out #OK
$ gcc quest-10a.c -O3 && ./a.out #OK
$ clang quest-10a.c -O0 && ./a.out #OK
$ clang quest-10a.c -O1 && ./a.out #FAIL
a.out: quest-10a.c:76: void callee_o0f(int, ...): Assertion `o69.o13.o8 ==
o82.o13.o8' failed.

reducing optimizations: (scalarrepl + instcombine)
#FAIL:
$ clang quest-10a.c -O0 -o test.bc -c -emit-llvm && opt test.bc -scalarrepl
-instcombine -o test2.bc && clang test2.bc && ./a.out 
a.out: quest-10a.c:76: void callee_o0f(int, ...): Assertion `o69.o13.o8 ==
o82.o13.o8' failed.

(there is no abort with instcombine or scalarrepl only 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  Wed May  4 07:52:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 07:52:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9839] New: missing negative options: -fno-pic and
	-fno-PIC
Message-ID: <bug-9839-206@http.llvm.org/bugs/>

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

           Summary: missing negative options: -fno-pic and -fno-PIC
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nobled at dreamwidth.org
                CC: llvmbugs at cs.uiuc.edu


I tested gcc's behavior when these flags are combined with their opposites on
an x86-32 Ubuntu install, and it actually seems to consider -fno-pic and
-fno-PIC to have the same meaning: don't define __pic__ or __PIC__ at all. Not
sure if that's a bug or intentional (I'd expected "-fpic -fno-PIC" to define
them to 1), since the behavior isn't specifically documented, just the fact
that "Most [options] have both positive and negative forms":
http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

$ gcc --version
gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
$ gcc -fsyntax-only pic.c -fpic -fPIC -fno-PIC
pic.c:3: error: #error __pic__ not defined
$ gcc -fsyntax-only pic.c -fpic -fPIC -fno-pic
pic.c:3: error: #error __pic__ not defined
$ gcc -fsyntax-only pic.c -fpic -fno-PIC
pic.c:3: error: #error __pic__ not defined
$ gcc -fsyntax-only pic.c -fno-PIC -fpic
pic.c:5: error: #error __pic__ equals 1
$ gcc -fsyntax-only pic.c -fno-pic -fPIC
pic.c:5: error: #error __pic__ equals 2
$ cat pic.c

#ifndef __pic__
#error __pic__ not defined
#elif __pic__ == 1
#error __pic__ equals 1
#elif __pic__ == 2
#error __pic__ equals 2
#else
#error WTF
#endif

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

From bugzilla-daemon at llvm.org  Wed May  4 07:59:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 07:59:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9840] New: assert with Greedy Register Allocator in
	linux
Message-ID: <bug-9840-206@http.llvm.org/bugs/>

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

           Summary: assert with Greedy Register Allocator in linux
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pageexec at freemail.hu
                CC: llvmbugs at cs.uiuc.edu, pageexec at freemail.hu
            Blocks: 4068


while compiling linux-2.6.38.4 with clang r130836 i get this assert:

  CC      arch/x86/lib/memcpy_32.o
clang: /llvm/llvm/lib/CodeGen/InlineSpiller.cpp:988: virtual
void<unnamed>::InlineSpiller::spill(llvm::LiveRangeEdit&): Assertion
`edit.getParent().isSpillable() && "Attempting to spill already spilled
value."' failed.
0  libLLVM-3.0svn.so 0xb2580d48
Stack dump:
0.      Program arguments: /llvm/build.i386/image/bin/clang -cc1 -triple
i386-pc-linux-gnu -emit-obj -disable-free -main-file-name memcpy_32.c
-mrelocation-model static -mregparm 3 -mdisable-fp-elim -relaxed-aliasing
-masm-verbose -mconstructor-aliases -no-implicit-float -target-cpu i686
-target-feature -sse -target-feature -sse -target-feature -mmx -target-feature
-sse2 -target-feature -3dnow -target-linker-version 2.21
-momit-leaf-frame-pointer -nostdinc -resource-dir
/llvm/build.i386/image/bin/../lib/clang/3.0 -dependency-file
arch/x86/lib/.memcpy_32.o.d -MT arch/x86/lib/memcpy_32.o -sys-header-deps
-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include -include
include/generated/autoconf.h -D __KERNEL__ -D CONFIG_AS_CFI=1 -D
CONFIG_AS_CFI_SIGNAL_FRAME=1 -D CONFIG_AS_CFI_SECTIONS=1 -D KBUILD_STR(s)=#s -D
KBUILD_BASENAME=KBUILD_STR(memcpy_32) -D KBUILD_MODNAME=KBUILD_STR(memcpy_32)
-I arch/x86/include -I include -Os -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -W -Wno-empty-body -Wno-unused-parameter
-Wno-missing-field-initializers -Wno-unused-value -Wno-format
-Wno-unknown-warning-option -Werror-implicit-function-declaration
-Wno-format-security -Wno-sign-compare -Wdeclaration-after-statement
-Wno-pointer-sign -ferror-limit 19 -fmessage-length 277 -ffreestanding -pg
-fwrapv -fgnu-runtime -fno-common -fdiagnostics-show-option -fcolor-diagnostics
-o arch/x86/lib/memcpy_32.o -x c arch/x86/lib/memcpy_32.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module
'arch/x86/lib/memcpy_32.c'.
4.      Running pass 'Greedy Register Allocator' on function '@memmove'
clang: error: unable to execute command: Aborted

the original source code:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=blob_plain;f=arch/x86/lib/memcpy_32.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 May  4 08:54:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 08:54:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3696] [meta] The FreeBSD source tree does not fully
 compile with Clang
In-Reply-To: <bug-3696-206@http.llvm.org/bugs/>
References: <bug-3696-206@http.llvm.org/bugs/>
Message-ID: <20110504135454.481352A6C12C@llvm.org>

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

Dimitry Andric <dimitry at andric.com> changed:

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

--- Comment #6 from Dimitry Andric <dimitry at andric.com> 2011-05-04 08:54:53 CDT ---
Ok, as of r130700, all components of FreeBSD compile with clang, at least for
i386 and x86_64.  So I'm closing this PR :)

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

From bugzilla-daemon at llvm.org  Wed May  4 11:49:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 11:49:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9841] New: Infinite loop in GVN
Message-ID: <bug-9841-206@http.llvm.org/bugs/>

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

           Summary: Infinite loop in GVN
           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: arushi987 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

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

From bugzilla-daemon at llvm.org  Wed May  4 12:58:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 12:58:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9842] New: Missing implementation of
 llvm::sys::fs::canonicalize
Message-ID: <bug-9842-206@http.llvm.org/bugs/>

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

           Summary: Missing implementation of llvm::sys::fs::canonicalize
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kyndigen at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I've grepped through the contents of the 2.9 release and a fresh checkout of
trunk from SVN.  I can find the prototype for fs::canonicalize(), but I can't
find an implementation of it.  If I try to use it, I get a link error.

Testcase:

------------------------------------------
#include <llvm/Support/FileSystem.h>

using namespace llvm;
using namespace llvm::sys;

int main() {
  SmallString<128> cpath;
  fs::canonicalize("/tmp", cpath);
  return 0;
}
-------------------------------------------

Results:

/tmp/clang $ g++ `llvm-config --cxxflags --ldflags --libs all`
canonicalize_bug.cpp
/tmp/cchybXUa.o: In function `main':
/tmp/clang/canonicalize_bug.cpp:8: undefined reference to
`llvm::sys::fs::canonicalize(llvm::Twine const&, llvm::SmallVectorImpl<char>&)'
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  Wed May  4 14:41:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 14:41:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9843] New: PCH crash with conflicting identifiers
Message-ID: <bug-9843-206@http.llvm.org/bugs/>

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

           Summary: PCH crash with conflicting identifiers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: scshunt at csclub.uwaterloo.ca
                CC: llvmbugs at cs.uiuc.edu


While attempting to hack around precompiled headers, I discovered that the
following managed to elicit a pure virtual function call crash. Filing
immediately; haven't performed any reduction yet.

// Test this without pch.
// RUN: %clang_cc1 -DPASS1 -DPASS2 -std=c++0x -fsyntax-only -verify %s

// Test with pch.
// RUN: %clang_cc1 -x c++-header -DPASS1 -std=c++0x -emit-pch -o %t %s
// RUN: %clang_cc1 -DPASS2 -std=c++0x -include-pch %t -fsyntax-only -verify %s 

#ifdef PASS1
struct foo {
  foo(int) : foo() { } // expected-note{{it delegates to}}
  foo();
};
#undef PASS1
#endif

#ifdef PASS2
foo::foo() : foo(1) { } // expected-error{{creates a delegation cycle}} \
                        // expected-note{{which delegates to}}
#endif

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

From bugzilla-daemon at llvm.org  Wed May  4 17:22:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 17:22:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9844] New: LLVM miscompiles dlls/cabinet/fdi.c from
	Wine
Message-ID: <bug-9844-206@http.llvm.org/bugs/>

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

           Summary: LLVM miscompiles dlls/cabinet/fdi.c from Wine
           Product: clang
           Version: trunk
          Platform: PC
               URL: http://bugs.winehq.org/show_bug.cgi?id=26755
        OS/Version: Linux
            Status: NEW
          Keywords: miscompilation
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: austinenglish at gmail.com
                CC: llvmbugs at cs.uiuc.edu, cdavis at mymail.mines.edu


Created an attachment (id=6531)
 --> (http://llvm.org/bugs/attachment.cgi?id=6531)
wine backtrace

Causes a crash in wine, when running wineboot (which doesn't get a good
backtrace), or when running the regression tests for dlls/cabinet.

I'll attach preprocessed C files from gcc and Clang.

clang version 3.0 (trunk 130866)

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

From bugzilla-daemon at llvm.org  Wed May  4 19:03:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 19:03:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9840] assert with Greedy Register Allocator in linux
In-Reply-To: <bug-9840-206@http.llvm.org/bugs/>
References: <bug-9840-206@http.llvm.org/bugs/>
Message-ID: <20110505000358.6EC162A6C12D@llvm.org>

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

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

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

--- Comment #5 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-04 19:03:57 CDT ---
Fixed in r130896 by disabling -join-physregs by default.

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

From bugzilla-daemon at llvm.org  Wed May  4 20:59:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  4 May 2011 20:59:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9845] New: clang crash with floating point exception
Message-ID: <bug-9845-206@http.llvm.org/bugs/>

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

           Summary: clang crash with floating point exception
           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 gamow tmp018]$ clang -c -w -O2 small.c
0  clang           0x00000000018e1acf
1  clang           0x00000000018e3d42
2  libpthread.so.0 0x00007ffff7bcf8f0
3  clang           0x00000000015dc881
4  clang           0x00000000015dde14
5  clang           0x00000000015de867
6  clang           0x00000000017042d4
llvm::LPPassManager::runOnFunction(llvm::Function&) + 1252
7  clang           0x000000000182e2cb
llvm::FPPassManager::runOnFunction(llvm::Function&) + 587
8  clang           0x000000000182e3cb
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
9  clang           0x000000000182ddc7
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
10 clang           0x000000000182df5b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
11 clang           0x00000000007c7dde
12 clang           0x00000000007c8a0d
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 189
13 clang           0x00000000007c53fb
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
14 clang           0x00000000008f525d clang::ParseAST(clang::Sema&, bool) + 413
15 clang           0x00000000007c4744 clang::CodeGenAction::ExecuteAction() +
68
16 clang           0x00000000006b09f3
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
17 clang           0x0000000000688124
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1268
18 clang           0x000000000067efdb cc1_main(char const**, char const**, char
const*, void*) + 683
19 clang           0x0000000000686f77 main + 6295
20 libc.so.6       0x00007ffff6ea9c4d __libc_start_main + 253
21 clang           0x000000000067d4a9
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r130907-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -coverage-file small.o -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r130907-install/bin/../lib/clang/3.0
-O2 -w -ferror-limit 19 -fmessage-length 81 -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 'Loop Pass Manager' on function '@func_37'
5.    Running pass 'Loop Strength Reduction' on basic block '%for.body'
clang: error: unable to execute command: Floating point exception
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at gamow tmp018]$ clang -v

clang version 3.0 (trunk 130907)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[regehr at gamow tmp018]$ cat small.c


long
safe_33 (int si1, long si2)
{
  return 0 ? 0 : si1 - si2;
}

int
safe_36 (long si1, int si2)
{
  return si1 == -9223372036854775807LL - 1;
}

int
safe_62 (int ui1, int ui2)
{
  return ui1 + 1;
}

int g_43;
int **
func_37 (p_38)
{
  for (0; 1; p_38 = safe_62 (p_38, 1))
    {
      int *l_42 = &g_43;
      if (safe_36 (safe_33 (p_38, *l_42), 0))
    {
    }
      else
    for (0; g_43; 1)
      {
      }
    }
}

int
main (void)
{
  return 0;
}

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

From bugzilla-daemon at llvm.org  Thu May  5 01:08:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 01:08:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9846] New: Assertion `B->end <= Start && "Cannot
 overlap two LiveRanges with differing ValID's" " (did you def the same reg
 twice in a MachineInstr?)"' failed.
Message-ID: <bug-9846-206@http.llvm.org/bugs/>

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

           Summary: Assertion `B->end <= Start && "Cannot overlap two
                    LiveRanges with differing ValID's" " (did you def the
                    same reg twice in a MachineInstr?)"' 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 gamow tmp019]$ clang -c -w -O2 small.c
clang: LiveInterval.cpp:267: llvm::LiveRange*
llvm::LiveInterval::addRangeFrom(llvm::LiveRange, llvm::LiveRange*): Assertion
`B->end <= Start && "Cannot overlap two LiveRanges with differing ValID's" "
(did you def the same reg twice in a MachineInstr?)"' failed.
0  clang           0x00000000018e1acf
1  clang           0x00000000018e3d42
2  libpthread.so.0 0x00007ffff7bcf8f0
3  libc.so.6       0x00007ffff6ebea75 gsignal + 53
4  libc.so.6       0x00007ffff6ec25c0 abort + 384
5  libc.so.6       0x00007ffff6eb7941 __assert_fail + 241
6  clang           0x0000000001543b8d
llvm::LiveInterval::addRangeFrom(llvm::LiveRange, llvm::LiveRange*) + 973
7  clang           0x000000000154b4ea
llvm::LiveIntervals::handleLiveInRegister(llvm::MachineBasicBlock*,
llvm::SlotIndex, llvm::LiveInterval&, bool) + 538
8  clang           0x0000000001552f84 llvm::LiveIntervals::computeIntervals() +
340
9  clang           0x00000000015536f3
llvm::LiveIntervals::runOnMachineFunction(llvm::MachineFunction&) + 627
10 clang           0x000000000182e2cb
llvm::FPPassManager::runOnFunction(llvm::Function&) + 587
11 clang           0x000000000182e3cb
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
12 clang           0x000000000182ddc7
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
13 clang           0x000000000182df5b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
14 clang           0x00000000007c7dde
15 clang           0x00000000007c8a0d
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 189
16 clang           0x00000000007c53fb
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
17 clang           0x00000000008f525d clang::ParseAST(clang::Sema&, bool) + 413
18 clang           0x00000000007c4744 clang::CodeGenAction::ExecuteAction() +
68
19 clang           0x00000000006b09f3
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
20 clang           0x0000000000688124
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1268
21 clang           0x000000000067efdb cc1_main(char const**, char const**, char
const*, void*) + 683
22 clang           0x0000000000686f77 main + 6295
23 libc.so.6       0x00007ffff6ea9c4d __libc_start_main + 253
24 clang           0x000000000067d4a9
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r130907-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -coverage-file small.o -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r130907-install/bin/../lib/clang/3.0
-O2 -w -ferror-limit 19 -fmessage-length 81 -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 'Live Interval Analysis' on function '@func_55'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at gamow tmp019]$ clang -v 

clang version 3.0 (trunk 130907)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[regehr at gamow tmp019]$ cat small.c


short
safe_14 (int si1, short si2)
{
  return si1 && si2 && (1 / si2) || si2 <= 0 && si2 < -32767 + si1 ? 0 : si2;
}

int g_61;
int g_90;
int
func_55 (int p_56, int p_57)
{
  int *l_60 = &g_61;
  int *l_346 = &g_90;
  *l_60 = safe_14 (1, *l_346 == 0);
  return 0;
}

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

From bugzilla-daemon at llvm.org  Thu May  5 09:56:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 09:56:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9847] New: mm_malloc.h generates an error
Message-ID: <bug-9847-206@http.llvm.org/bugs/>

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

           Summary: mm_malloc.h generates an error
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: yottui at yahoo.co.jp
                CC: llvmbugs at cs.uiuc.edu


I'm using clang++ 2.9 and MinGW-gcc 4.5.2.
At that time, the compiler generates an error.

--- begin test case (xmmintrin.cpp) ---
#include <xmmintrin.h>
--- end test case ---

--- begin operation ---
$ clang++ -c -msse xmmintrin.cpp
In file included from xmmintrin.cpp:1:
In file included from C:/MinGW/bin/../lib/clang/2.9/include/xmmintrin.h:40:
C:/MinGW/bin/../lib/clang/2.9/include/mm_malloc.h:57:20: error: use of
undeclared identifier '_aligned_malloc'
  mallocedMemory = _aligned_malloc(size, align);
                   ^
1 error generated.
--- end operation ---

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  5 10:19:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 10:19:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9848] New: _mm_andnot_si64() is broken
Message-ID: <bug-9848-206@http.llvm.org/bugs/>

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

           Summary: _mm_andnot_si64() is broken
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: yottui at yahoo.co.jp
                CC: llvmbugs at cs.uiuc.edu


clang++ 2.9 generates a wrong code with _mm_andnot_si64().
Ths source register and the destination register are swapped in PANDN.

--- begin test case (andnot.cpp) ---
#include <mmintrin.h>

__m64 max_pu16(__m64 lhs, __m64 rhs)
{
    __m64 sign = _mm_set1_pi16((short)0x8000);
    __m64 ls   = _mm_xor_si64(lhs, sign);
    __m64 rs   = _mm_xor_si64(rhs, sign);
    __m64 mask = _mm_cmpgt_pi16(ls, rs);
    __m64 gt   = _mm_and_si64(mask, lhs);
    __m64 le   = _mm_andnot_si64(mask, rhs);

    return _mm_or_si64(gt, le);
}
--- end test case ---

--- begin output ---
$ clang++ -O -S -mmmx -mno-sse -mno-sse2 -D _mm_malloc andnot.cpp

$ cat andnot.s
    .def     __Z8max_pu16Dv1_xS_;
    .scl    2;
    .type    32;
    .endef
    .text
    .globl    __Z8max_pu16Dv1_xS_
    .align    16, 0x90
__Z8max_pu16Dv1_xS_:
    subl    $68, %esp
    movl    84(%esp), %eax ; rhs[1]
    movl    %eax, 44(%esp) ;   -> 44(esp)
    movl    80(%esp), %eax ; rhs[0]
    movl    %eax, 40(%esp) ;   -> 40(esp)
    movl    76(%esp), %eax ; lhs[1]
    movl    %eax, 52(%esp) ;   -> 52(esp)
    movl    72(%esp), %eax ; lhs[0]
    movl    %eax, 48(%esp) ;   -> 48(esp)
    movl    $-2147450880, 60(%esp) ; 0x8000 -> 60(esp)
    movl    $-2147450880, 56(%esp) ; 0x8000 -> 56(esp)
    movq    56(%esp), %mm0 ; 0x8000 -> mm0
    movq    40(%esp), %mm1 ; rhs -> mm1
    movq    %mm1, %mm2     ; rhs -> mm2
    pxor    %mm0, %mm2     ; 0x8000 ^ rhs -> mm2 = rs
    movq    48(%esp), %mm3 ; lhs -> mm3
    pxor    %mm3, %mm0     ; lhs ^ 0x8000 -> mm0 = ls
    pcmpgtw    %mm2, %mm0     ; rs < ls
    movq    %mm0, 8(%esp)  ;              ->  8(esp) = mask
    movl    8(%esp), %eax  ;  8(esp)      -> eax
    movl    12(%esp), %ecx ; 12(esp)      -> ecx
    movl    %ecx, 20(%esp) ; ecx          -> 20(esp)
    movl    %eax, 16(%esp) ; eax          -> 16(esp)
    movq    16(%esp), %mm0 ; mask         -> mm0
    pandn    %mm0, %mm1     ; mask & ~rhs  -> mm1 = le !!!!!! wrong code !!!!!
    pand    %mm3, %mm0     ; lhs  & mask  -> mm0 = gt
    por    %mm1, %mm0         ; le | gt -> mm0
    movq    %mm0, (%esp)
    movl    (%esp), %eax
    movl    4(%esp), %edx
    addl    $68, %esp
    ret
--- end output ---

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  5 10:23:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 10:23:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9849] New: The elements of the result of
 _mm_setr_pi16() and _mm_setr_pi32() are swapped
Message-ID: <bug-9849-206@http.llvm.org/bugs/>

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

           Summary: The elements of the result of _mm_setr_pi16() and
                    _mm_setr_pi32() are swapped
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: yottui at yahoo.co.jp
                CC: llvmbugs at cs.uiuc.edu


_mm_setr_pi16() and _mm_setr_pi32() are defined in
lib/clang/2.9/include/mmintrin.h
But these function parameters are swapped.

--- begin mmintrin.h ---
static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
_mm_setr_pi32(int __i1, int __i0)
{
    return _mm_set_pi32(__i1, __i0);
}

static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
_mm_setr_pi16(short __w3, short __w2, short __w1, short __w0)
{
    return _mm_set_pi16(__w3, __w2, __w1, __w0);
}
--- end mmintrin.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  Thu May  5 10:31:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 10:31:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9850] New: _mm_cmpgt_epi32() is broken
Message-ID: <bug-9850-206@http.llvm.org/bugs/>

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

           Summary: _mm_cmpgt_epi32() is broken
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: yottui at yahoo.co.jp
                CC: llvmbugs at cs.uiuc.edu


_mm_cmpgt_epi32() does not generate PCMPGT.

--- begin test case (cmpgt.cpp) ---
#include <emmintrin.h>

__m128i has_carry(__m128i lhs, __m128i rhs)
{
    __m128i add   = _mm_add_epi32(lhs, rhs);
    __m128i carry = _mm_cmpgt_epi32(lhs, add);

    return carry;
}
--- end test case ---

--- begin output ---
$ clang++ -O -S -msse2 -D _mm_malloc cmpgt.cpp

$ cat cmpgt.s

    .def     __Z9has_carryDv2_xS_;
    .scl    2;
    .type    32;
    .endef
    .text
    .globl    __Z9has_carryDv2_xS_
    .align    16, 0x90
__Z9has_carryDv2_xS_:
    movdqa    %xmm1, %xmm0
    psrad    $31, %xmm0
    ret
--- end output ---

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  5 11:18:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 11:18:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9846] Assertion `B->end <= Start && "Cannot overlap
 two LiveRanges with differing ValID's" " (did you def the same reg twice in
 a MachineInstr?)"' failed.
In-Reply-To: <bug-9846-206@http.llvm.org/bugs/>
References: <bug-9846-206@http.llvm.org/bugs/>
Message-ID: <20110505161858.BCFD12A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-05 11:18:58 CDT ---
r130925; thanks a bunch for the testcase!

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

From bugzilla-daemon at llvm.org  Thu May  5 12:04:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 12:04:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8361] duplicated compare instruction
In-Reply-To: <bug-8361-206@http.llvm.org/bugs/>
References: <bug-8361-206@http.llvm.org/bugs/>
Message-ID: <20110505170433.4C7302A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-05 12:04:32 CDT ---
r130928.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  5 12:45:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 12:45:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9848] _mm_andnot_si64() is broken
In-Reply-To: <bug-9848-206@http.llvm.org/bugs/>
References: <bug-9848-206@http.llvm.org/bugs/>
Message-ID: <20110505174544.6C4252A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-05 12:45:44 CDT ---
r130932.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  5 13:43:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 13:43:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9851] New: llc -combiner-alias-analysis reorders
	volatiles
Message-ID: <bug-9851-206@http.llvm.org/bugs/>

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

           Summary: llc -combiner-alias-analysis reorders volatiles
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hausen at gmx.at
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6546)
 --> (http://llvm.org/bugs/attachment.cgi?id=6546)
Test case for reordering of volatiles.

llc reorders accesses to volatiles if -combiner-alias-analysis is enabled,
although volatiles should not be reordered with regard to each other.

Testcase, which miscompiles at least for sparc and ppc32:
define i32 @test() {
  %X = volatile load i32* inttoptr(i32 8 to i32*)
  %Y = volatile load i32* inttoptr(i32 12 to i32*)
  %Z = add i32 %Y, 1000
  ret i32 %Z
}

Correct code, from llc -march=ppc32
  lwz 3, 8(0)
  lwz 3, 12(0)
  addi 3, 3, 1000
  blr 

Miscompiled code, from llc -march=ppc32 -combiner-alias-analysis
  lwz 3, 12(0)
  lwz 4, 8(0)
  addi 3, 3, 1000
  blr

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

From bugzilla-daemon at llvm.org  Thu May  5 15:18:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 15:18:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9852] New: Assertion failure with invalid C++ code
Message-ID: <bug-9852-206@http.llvm.org/bugs/>

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

           Summary: Assertion failure with invalid C++ code
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: andersca at mac.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


struct A {
  virtual void f() = 0;

  A();
};

A::A() {
  void A::(*f)();
}


The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Users/andersca/src/llvm/build/bin/Debug/clang -cc1
-fsyntax-only t.cpp
Assertion failed: (!EnteredScope && "Already entered the scope!"), function
EnterDeclaratorScope, file
/Users/andersca/src/llvm/tools/clang/include/clang/Parse/Parser.h, line 1669.

Program received signal SIGABRT, Aborted.
0x00007fff87a16cba in __pthread_kill ()

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  5 15:22:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 15:22:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9849] The elements of the result of _mm_setr_pi16()
 and _mm_setr_pi32() are swapped
In-Reply-To: <bug-9849-206@http.llvm.org/bugs/>
References: <bug-9849-206@http.llvm.org/bugs/>
Message-ID: <20110505202212.E1F132A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-05 15:22:12 CDT ---
r130945.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  5 17:00:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 17:00:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9838] r130717 breaks quest tests
In-Reply-To: <bug-9838-206@http.llvm.org/bugs/>
References: <bug-9838-206@http.llvm.org/bugs/>
Message-ID: <20110505220018.649C42A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #7 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-05 17:00:18 CDT ---
r130954.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  5 18:38:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 18:38:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9853] New: Friends allowed to define member
	functions
Message-ID: <bug-9853-206@http.llvm.org/bugs/>

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

           Summary: Friends allowed to define member functions
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: scshunt at csclub.uwaterloo.ca
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


We accept the following:

struct bar {
 void baz();
};

struct foo {
  friend void bar::baz() { }
};

which is ill-formed as bar::baz is a) a qualified-name and b) not at namespace
scope. We should error 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 May  5 19:52:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  5 May 2011 19:52:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9854] New: <cmath> undefs symbols from the global
	namespace
Message-ID: <bug-9854-206@http.llvm.org/bugs/>

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

           Summary: <cmath> undefs symbols from the global namespace
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


$ cat test.cc
#include <math.h>

void foo(double works) {
    isnan(works);
}

#include <cmath>

void bar(double doesnt) {
    isnan(doesnt);
}
$ clang++ -stdlib=libc++ -c test.cc 
test.cc:10:5: error: use of undeclared identifier 'isnan'
    isnan(doesnt);
    ^
1 error generated.


This is basically the same issue as http://gcc.gnu.org/PR14608.
[depr.c.headers] says that <math.h> puts the <cmath> names into the global
namespace, and it doesn't allow a later include of <cmath> to take them back
out. [depr.c.headers] also allows <cmath> to 'using' its declarations and
definitions into the global namespace, which is what I'd propose as a fix.

One twist is that glibc's <math.h> defines at least isnan and isinf as
functions in the global namespace rather than just macros, so you can't simply
add that using declaration on all platforms.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 01:16:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 01:16:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9851] llc -combiner-alias-analysis reorders
	volatiles
In-Reply-To: <bug-9851-206@http.llvm.org/bugs/>
References: <bug-9851-206@http.llvm.org/bugs/>
Message-ID: <20110506061654.558802A6C12C@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-05-06 01:16:53 CDT ---
As far as I know reordering volatiles is perfectly valid.  You need a memory
barrier if you want to enforce ordering.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 01:54:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 01:54:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9851] llc -combiner-alias-analysis reorders
	volatiles
In-Reply-To: <bug-9851-206@http.llvm.org/bugs/>
References: <bug-9851-206@http.llvm.org/bugs/>
Message-ID: <20110506065435.DBB8B2A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-06 01:54:35 CDT ---
(In reply to comment #2)
> As far as I know reordering volatiles is perfectly valid.  You need a memory
> barrier if you want to enforce ordering.

>From LangRef: "The optimizers must not change the number of volatile operations
or change their order of execution relative to other volatile operations."

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

From bugzilla-daemon at llvm.org  Fri May  6 03:43:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 03:43:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9855] New: trying to call an inlined function,
 causing link failure
Message-ID: <bug-9855-206@http.llvm.org/bugs/>

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

           Summary: trying to call an inlined function, causing link
                    failure
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: if.html at gmail.com
                CC: llvmbugs at cs.uiuc.edu


code:

#include <stdio.h>
inline unsigned int f(unsigned int x){
    if(x%2==0) {
        return x/2;
    } else {
        return 3*x+1;
    }
}
int main(){
    unsigned int x;
    for(scanf("%d",&x); x!=1; printf("%d\n", x))
        x=f(x);
    return 0;
}

---------
what clang compiles to:

    .def     _main;
    .scl    2;
    .type    32;
    .endef
    .text
    .globl    _main
    .align    16, 0x90
_main:
    pushl    %ebp
    movl    %esp, %ebp
    subl    $24, %esp
    calll    ___main
    leal    L_.str, %eax
    leal    -8(%ebp), %ecx
    movl    $0, -4(%ebp)
    movl    %eax, (%esp)
    movl    %ecx, 4(%esp)
    calll    _scanf
    movl    %eax, -12(%ebp)
LBB0_1:
    cmpl    $1, -8(%ebp)
    je    LBB0_4
    movl    -8(%ebp), %eax
    movl    %eax, (%esp)
    calll    _f              ; <=== here
    movl    %eax, -8(%ebp)
    leal    L_.str1, %eax
    movl    -8(%ebp), %ecx
    movl    %eax, (%esp)
    movl    %ecx, 4(%esp)
    calll    _printf
    movl    %eax, -16(%ebp)
    jmp    LBB0_1
LBB0_4:
    movl    $0, %eax
    addl    $24, %esp
    popl    %ebp
    ret

    .data
L_.str:
    .asciz     "%d"

L_.str1:
    .asciz     "%d\n"

------

BTW, with -O2 option, clang generates correct assembly

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 05:31:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 05:31:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9820] output crashes, but should not
In-Reply-To: <bug-9820-206@http.llvm.org/bugs/>
References: <bug-9820-206@http.llvm.org/bugs/>
Message-ID: <20110506103119.296362A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #7 from Duncan Sands <baldrick at free.fr> 2011-05-06 05:31:18 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110502/120486.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 May  6 09:16:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 09:16:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9856] New: Assertion `(isa<PHINode>(GlobalUser) ||
 isa<SelectInst>(GlobalUser) || isa<ConstantExpr>(GlobalUser)) && "Only
 expect load and stores!"' failed.
Message-ID: <bug-9856-206@http.llvm.org/bugs/>

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

           Summary: Assertion `(isa<PHINode>(GlobalUser) ||
                    isa<SelectInst>(GlobalUser) ||
                    isa<ConstantExpr>(GlobalUser)) && "Only expect load
                    and stores!"' 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 gamow tmp021]$ clang -O small.c -c -w
clang: GlobalOpt.cpp:802: bool
OptimizeAwayTrappingUsesOfLoads(llvm::GlobalVariable*, llvm::Constant*):
Assertion `(isa<PHINode>(GlobalUser) || isa<SelectInst>(GlobalUser) ||
isa<ConstantExpr>(GlobalUser)) && "Only expect load and stores!"' failed.
0  clang           0x00000000018e308f
1  clang           0x00000000018e5302
2  libpthread.so.0 0x00007ffff7bcf8f0
3  libc.so.6       0x00007ffff6ebea75 gsignal + 53
4  libc.so.6       0x00007ffff6ec25c0 abort + 384
5  libc.so.6       0x00007ffff6eb7941 __assert_fail + 241
6  clang           0x0000000000ebb68d
7  clang           0x0000000000ebe3a0
8  clang           0x0000000000ebf0fb
9  clang           0x0000000000ebf5ad
10 clang           0x000000000182f377
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
11 clang           0x000000000182f50b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
12 clang           0x00000000007c8a08
13 clang           0x00000000007c968d
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 189
14 clang           0x00000000007c607b
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
15 clang           0x00000000008f5efd clang::ParseAST(clang::Sema&, bool) + 413
16 clang           0x00000000007c53c4 clang::CodeGenAction::ExecuteAction() +
68
17 clang           0x00000000006b1583
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
18 clang           0x0000000000688b84
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1268
19 clang           0x000000000067fa3b cc1_main(char const**, char const**, char
const*, void*) + 683
20 clang           0x00000000006879d7 main + 6295
21 libc.so.6       0x00007ffff6ea9c4d __libc_start_main + 253
22 clang           0x000000000067df09
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r130980-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -coverage-file small.o -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r130980-install/bin/../lib/clang/3.0
-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 'Global Variable Optimizer' on module 'small.c'.
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)
[regehr at gamow tmp021]$ clang -v
clang version 3.0 (trunk 130980)
Target: x86_64-unknown-linux-gnu
Thread model: posix
[regehr at gamow tmp021]$ cat small.c
struct S0 {
  int f3;
  int f6;
  int f8;
};

static int **g_52;

int *g_90;

struct S0 g_175[0] = {
};

int func_47 (int, int, int **p_50, int);

unsigned long long func_9 (unsigned short p_10) {
  int l_18[2] = { 0, 0 };
  if (l_18[1], l_18[1], func_47 (0, 0, g_52, 1), g_175[0].f8, g_175[0].f3)
    ;
  int **l_203[0];
  int ***l_208 = &l_203[0];
  int **l_117 = &g_90;
  int ***l_118 = &g_52;
  *l_118 = l_117;
  g_175[0].f6 <= g_175[0].f8 || l_208 != &g_52;
  return 0;
}

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

From bugzilla-daemon at llvm.org  Fri May  6 09:26:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 09:26:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7966] missing warning about use of virtual member
 inside destructor
In-Reply-To: <bug-7966-206@http.llvm.org/bugs/>
References: <bug-7966-206@http.llvm.org/bugs/>
Message-ID: <20110506142612.C19B72A6C124@llvm.org>

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

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> 2011-05-06 09:26:12 CDT ---
Committed revision 130982.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 09:36:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 09:36:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9290] [MC] Conditional jumps are encoded
	sub-optimally
In-Reply-To: <bug-9290-206@http.llvm.org/bugs/>
References: <bug-9290-206@http.llvm.org/bugs/>
Message-ID: <20110506143639.4C2E62A6C12E@llvm.org>

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

J?rg Sonnenberger <joerg at NetBSD.org> changed:

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

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

From bugzilla-daemon at llvm.org  Fri May  6 10:26:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 10:26:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9857] New: llvm bitcode writer assertion failed
Message-ID: <bug-9857-206@http.llvm.org/bugs/>

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

           Summary: llvm bitcode writer assertion failed
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Bitcode Writer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: quickslyver at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6549)
 --> (http://llvm.org/bugs/attachment.cgi?id=6549)
bug.c

bug.c is 990208-1.c from gcc torture suite

$clang bug.c -O2 -c -emit-llvm

clang-3.0: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:875: void
WriteConstants(unsigned int, unsigned int, const llvm::ValueEnumerator&,
llvm::BitstreamWriter&, bool): Assertion `BA->getFunction() ==
BA->getBasicBlock()->getParent() && "Malformed blockaddress"' failed.
Stack dump:
0.    Program arguments: llvm-build/bin/clang-3.0 -cc1 -triple
i386-pc-linux-gnu -emit-llvm-bc -disable-free -main-file-name bug.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -momit-leaf-frame-pointer -coverage-file bug.o
-resource-dir llvm-build/bin/../lib/clang/3.0 -O2 -ferror-limit 19
-fmessage-length 117 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o bug.o -x c bug.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'Bitcode Writer' on module 'bug.c'.
clang-3: error: unable to execute command: Aborted
clang-3: 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  Fri May  6 12:22:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 12:22:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9858] New: targetdata strings starting with "-"
 causing assertion failures
Message-ID: <bug-9858-206@http.llvm.org/bugs/>

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

           Summary: targetdata strings starting with "-" causing assertion
                    failures
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Target Description Classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bob.wilson at apple.com
                CC: llvmbugs at cs.uiuc.edu


The llvm-gcc-x86_64-linux-selfhost and clang-x86_64-linux-selfhost-rel
buildbots, running on osu7, have been failing since 5/2/11:

http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2011-May/032970.html
http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2011-May/032971.html

The symptom is that tests containing targetdata strings beginning with "-",
e.g., "-p:64:64:64", get assertion failures like this:

opt:
/build/buildbot-llvm/clang-x86_64-linux-selfhost-rel/llvm.src/lib/Target/TargetData.cpp:166:
void llvm::TargetData::init(llvm::StringRef): Assertion `!Specifier.empty() &&
"Can't be empty here"' failed.
0  opt             0x000000000091148f
1  opt             0x0000000000911989
2  libpthread.so.0 0x00002b4fe7e86020
3  libc.so.6       0x00002b4fe8a6d415 gsignal + 53
4  libc.so.6       0x00002b4fe8a70690 abort + 384
5  libc.so.6       0x00002b4fe8a665c1 __assert_fail + 241
6  opt             0x00000000007a08bd llvm::TargetData::init(llvm::StringRef) +
1933
7  opt             0x00000000004bf346 main + 2454
8  libc.so.6       0x00002b4fe8a59eed __libc_start_main + 253
9  opt             0x00000000004acaa9

I don't see anything that changes around that time that would cause this, and
we're not seeing it on any other testers, but it would be good to get those
buildbots fixed soon.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 12:44:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 12:44:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9855] trying to call an inlined function,
	causing link failure
In-Reply-To: <bug-9855-206@http.llvm.org/bugs/>
References: <bug-9855-206@http.llvm.org/bugs/>
Message-ID: <20110506174438.A3E6E2A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-06 12:44:38 CDT ---
If your program GNU-style inline semantics, either fix it to use C99 semantics,
or pass -std=gnu89 to 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  Fri May  6 13:04:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 13:04:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9850] _mm_cmpgt_epi32() is broken
In-Reply-To: <bug-9850-206@http.llvm.org/bugs/>
References: <bug-9850-206@http.llvm.org/bugs/>
Message-ID: <20110506180446.75CE42A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-06 13:04:45 CDT ---
r131000.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 13:08:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 13:08:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9859] New: internal compiler error: in extract_insn,
 at recog.c:2031
Message-ID: <bug-9859-206@http.llvm.org/bugs/>

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

           Summary: internal compiler error: in extract_insn, at
                    recog.c:2031
           Product: new-bugs
           Version: 2.9
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gryffindor.godric at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Compilation of LLVM version 2.9 fails on PowerPC architecture, with the
following error:

llvm[3]: Compiling PPCISelLowering.cpp for Release build
PPCISelLowering.cpp: In member function ?llvm::SDValue
llvm::PPCTargetLowering::LowerFormalArguments_SVR4(llvm::SDValue,
llvm::CallingConv::ID, bool, const llvm::SmallVectorImpl<llvm::ISD::InputArg>&,
llvm::DebugLoc, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&)
const?:
PPCISelLowering.cpp:1772: error: unrecognizable insn:
(insn 2370 2369 1450 120
/tmp/llvm/llvm-2.8/include/llvm/CodeGen/ValueTypes.h:233 (set (reg:SI 11 11)
        (mem/u/c/i:SI (symbol_ref/u:SI ("*.LC233") [flags 0x82]) [8 S4 A32]))
-1 (insn_list:REG_LABEL_OPERAND 1454 (nil)))
PPCISelLowering.cpp:1772: internal compiler error: in extract_insn, at
recog.c:2031
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.opensuse.org/> for instructions.
/bin/rm: cannot remove
`/tmp/llvm/llvm-2.8/lib/Target/PowerPC/Release/PPCISelLowering.d.tmp': No such
file or directory
make[3]: *** [/tmp/llvm/llvm-2.8/lib/Target/PowerPC/Release/PPCISelLowering.o]
Error 1

OS Details:

Kernel Version (as reported by uname -a): 2.6.27.56-0.1-ppc64 #1 SMP 2010-12-01
16:57:58 +0100 ppc64 ppc64 ppc64 GNU/Linux

GCC Version (as reported by gcc -v): Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=default32
--enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) 

Distribution/Version:openSUSE 11.1 (ppc)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 13:13:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 13:13:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9859] internal compiler error: in extract_insn,
	at recog.c:2031
In-Reply-To: <bug-9859-206@http.llvm.org/bugs/>
References: <bug-9859-206@http.llvm.org/bugs/>
Message-ID: <20110506181344.E94622A6C124@llvm.org>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2011-05-06 13:13:44 CDT ---
This is bug in your system gcc. Please report this to OpenSUSE / gcc bugzilla.

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

From bugzilla-daemon at llvm.org  Fri May  6 15:57:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 15:57:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4668] "Ran out of registers during register
 allocation" on x86-32 with asm using only 6 registers
In-Reply-To: <bug-4668-206@http.llvm.org/bugs/>
References: <bug-4668-206@http.llvm.org/bugs/>
Message-ID: <20110506205702.CA3B32A6C124@llvm.org>

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

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

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

--- Comment #11 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-06 15:57:01 CDT ---
This is likely to have been fixed by disabling physical register coalescing,
but I can no longer make the test case fail.
Please verify with trunk.

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

From bugzilla-daemon at llvm.org  Fri May  6 16:00:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 16:00:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8051] Linear Scan Register Allocator crash on mixed
 register classes / high pressure
In-Reply-To: <bug-8051-206@http.llvm.org/bugs/>
References: <bug-8051-206@http.llvm.org/bugs/>
Message-ID: <20110506210036.DCC1D2A6C12E@llvm.org>

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

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

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

--- Comment #11 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-06 16:00:35 CDT ---
Physreg coalescing has been disabled.
Not that I couldn't reproduce this problem even with -join-physregs, though.

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

From bugzilla-daemon at llvm.org  Fri May  6 16:09:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 16:09:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9857] llvm bitcode writer assertion failed
In-Reply-To: <bug-9857-206@http.llvm.org/bugs/>
References: <bug-9857-206@http.llvm.org/bugs/>
Message-ID: <20110506210957.125E22A6C12C@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #2 from Nick Lewycky <nlewycky at google.com> 2011-05-06 16:09:56 CDT ---
Fixed in r131016.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 16:46:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 16:46:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9860] New: Clang "no viable conversion" bug with
 operator overload
Message-ID: <bug-9860-206@http.llvm.org/bugs/>

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

           Summary: Clang "no viable conversion" bug with operator
                    overload
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: d235j.1 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


When compiling the attached preprocessed source file, I get the following
error:


In file included from src/emu/emuopts.c:1:
src/emu/emuopts.c:459:31: error: no viable conversion from 'emu_file' to
'core_file' (aka '_core_file')
 bool result = parse_ini_file(file, priority, OPTION_PRIORITY_DRIVER_INI,
error);
                              ^~~~
src/emu/fileio.h:118:2: note: candidate function
 operator core_file &();
 ^
src/lib/util/options.h:163:33: note: passing argument to parameter 'inifile'
here
 bool parse_ini_file(core_file &inifile, int priority, int ignore_priority,
astring &error_string);
                                ^
1 error generated.


There could be a bug in the code, but I can't find 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  Fri May  6 17:19:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 17:19:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9861] New: clang -E produces output that clang
	doesn't like
Message-ID: <bug-9861-206@http.llvm.org/bugs/>

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

           Summary: clang -E produces output that clang doesn't like
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ cat foobar.c
#include "foobar.h"
$ cat foobar.h
#pragma GCC system_header
$ clang -c foobar.c
$ gcc -c foobar.c
$ gcc -c foobar.c -save-temps
$ cat foobar.i
# 1 "foobar.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "foobar.c"
# 1 "foobar.h" 1

# 1 "foobar.h" 3
# 1 "foobar.c" 2
$ clang -c foobar.c -save-temps
In file included from foobar.c:1:
In file included from foobar.c:1:
./foobar.h:1:3: error: line marker directive requires a positive integer
argument
# 0 "./foobar.h"
  ^
./foobar.h:2:3: error: line marker directive requires a positive integer
argument
# 0 "./foobar.h" 3
  ^
2 errors generated.
$ cat foobar.i
# 1 "foobar.c"
# 1 "foobar.c" 1
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 132 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "foobar.c" 2
# 1 "./foobar.h" 1
# 0 "./foobar.h"
# 0 "./foobar.h" 3
# 2 "foobar.c" 2

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

From bugzilla-daemon at llvm.org  Fri May  6 19:35:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 19:35:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9862] New: clang can't link with -g on darwin if
 POSIXLY_CORRECT environmental is set
Message-ID: <bug-9862-206@http.llvm.org/bugs/>

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

           Summary: clang can't link with -g on darwin if POSIXLY_CORRECT
                    environmental is set
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6551)
 --> (http://llvm.org/bugs/attachment.cgi?id=6551)
testcase demonstrating broken call to dsymutil when POSIXLY_CORRECT env is set

Currently if the POSIXLY_CORRECT environmental is set and -g is used in clang,
the resulting call to dsymutil fails...

frodo:~] howarth% /sw/opt/llvm-2.9/bin/clang -v -o conftest -g -O2 conftest.c
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-apple-darwin10
Thread model: posix
 "/sw/opt/llvm-2.9/bin/clang-2.9" -cc1 -triple x86_64-apple-darwin10.0.0
-emit-obj -disable-free -disable-llvm-verifier -main-file-name conftest.c
-pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-v -g -resource-dir /sw/opt/llvm-2.9/bin/../lib/clang/2.9 -O2 -ferror-limit 19
-fmessage-length 136 -stack-protector 1 -fblocks -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-JYeXyF.o -x c conftest.c
clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-apple-darwin10
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/opt/llvm-2.9/bin/../lib/clang/2.9/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld" -dynamic -arch x86_64
-macosx_version_min 10.6.0 -o conftest -lcrt1.10.6.o /tmp/cc-JYeXyF.o -lSystem
 "/usr/bin/dsymutil" conftest -o conftest.dSYM
error: unable to open executable '-o'
clang-2: error: dsymutil command failed with exit code 1 (use -v to see
invocation)

whereas without setting POSIXLY_CORRECT, the same test case links fine...

[frodo:~] howarth% /sw/opt/llvm-2.9/bin/clang  -v -o conftest -g -O2 conftest.c
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-apple-darwin10
Thread model: posix
 "/sw/opt/llvm-2.9/bin/clang-2.9" -cc1 -triple x86_64-apple-darwin10.0.0
-emit-obj -disable-free -disable-llvm-verifier -main-file-name conftest.c
-pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-v -g -resource-dir /sw/opt/llvm-2.9/bin/../lib/clang/2.9 -O2 -ferror-limit 19
-fmessage-length 136 -stack-protector 1 -fblocks -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-7gdqNX.o -x c conftest.c
clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-apple-darwin10
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/opt/llvm-2.9/bin/../lib/clang/2.9/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld" -dynamic -arch x86_64
-macosx_version_min 10.6.0 -o conftest -lcrt1.10.6.o /tmp/cc-7gdqNX.o -lSystem
 "/usr/bin/dsymutil" conftest -o conftest.dSYM

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 19:55:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 19:55:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9863] New: gcc front-end compilation: getting
 error: exec: -Q: invalid option
Message-ID: <bug-9863-206@http.llvm.org/bugs/>

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

           Summary: gcc front-end compilation: getting error: exec: -Q:
                    invalid option
           Product: new-bugs
           Version: 2.8
          Platform: DEC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sogania at synopsys.com
                CC: llvmbugs at cs.uiuc.edu


i am trying to build the gcc-frontend from source (version 2.8). Have already
built the LLVM part. Using gcc-4.2.2.
(configure and make command below). While building, get this error:
/remote/vtgtools/llvm/llvm-gcc-4.2-2.8.source/obj/./gcc/xgcc
-B/remote/vtgtools/llvm/llvm-gcc-4.2-2.8.source/obj/./gcc/
-B/remote/vtgtools/llvm/llvm-gcc-4.2-2.8.source/obj/../install/i686-pc-linux-gnu/bin/
-B/remote/vtgtools/llvm/llvm-gcc-4.2-2.8.source/obj/../install/i686-pc-linux-gnu/lib/
-isystem
/remote/vtgtools/llvm/llvm-gcc-4.2-2.8.source/obj/../install/i686-pc-linux-gnu/include
-isystem
/remote/vtgtools/llvm/llvm-gcc-4.2-2.8.source/obj/../install/i686-pc-linux-gnu/sys-include
-O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber
-I/remote/vtgtools/llvm/llvm-2.8/include -g0 -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-toplevel-reorder -Dinhibit_libc -fno-omit-frame-pointer -c
../../gcc/crtstuff.c -DCRT_BEGIN -o crtbegin.o 
/remote/vtgtools/llvm/llvm-gcc-4.2-2.8.source/obj/./gcc/as: line 2: exec: -Q:
invalid option
exec: usage: exec [-cl] [-a name] file [redirection ...]

Unable to figure out where "-Q" is coming from.  Need help with this.

Configure command:
../configure --prefix=`pwd`/../install --program-prefix=llvm-
--enable-llvm=$LLVMOBJDIR --enable-languages=c,c++ --target=i686-pc-linux-gnu
--with-tune=generic --with-arch=pentium4

setenv LLVMOBJDIR /remote/vtgtools/llvm/llvm-2.8

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 20:06:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 20:06:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9863] gcc front-end compilation: getting error:
 exec: -Q: invalid option
In-Reply-To: <bug-9863-206@http.llvm.org/bugs/>
References: <bug-9863-206@http.llvm.org/bugs/>
Message-ID: <20110507010637.3FEC02A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-06 20:06:36 CDT ---
I'm sorry, but LLVM 2.8 is really old and llvm-gcc is no longer supported.
Please try dragonegg with mainline LLVM, or Clang if you're interested in the C
family of languages.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  6 21:36:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  6 May 2011 21:36:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9864] New: crash after error using sizeof on class
 with incomplete array member
Message-ID: <bug-9864-206@http.llvm.org/bugs/>

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

           Summary: crash after error using sizeof on class with
                    incomplete array member
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


<stdin>:1:16: error: field has incomplete type 'int []'
struct S { int xs[]; int n; S() : n(sizeof(S)) { } };
               ^

clang: /home/tla/Projects/llvm/src/tools/clang/lib/Sema/SemaDeclCXX.cpp:2226:
bool clang::Sema::SetCtorInitializers(clang::CXXConstructorDecl*,
clang::CXXCtorInitializer**, unsigned int, bool): Assertion
`ClassDecl->hasFlexibleArrayMember() && "Incomplete array type is not valid"'
failed.
0  libLLVM-3.0svn.so 0x00007f25420d67ef
1  libLLVM-3.0svn.so 0x00007f25420d8a62
2  libpthread.so.0   0x00007f25410418f0
3  libc.so.6         0x00007f2540330a75 gsignal + 53
4  libc.so.6         0x00007f25403345c0 abort + 384
5  libc.so.6         0x00007f2540329941 __assert_fail + 241
6  clang             0x00000000008afd50
clang::Sema::SetCtorInitializers(clang::CXXConstructorDecl*,
clang::CXXCtorInitializer**, unsigned int, bool) + 4416
7  clang             0x00000000008b0f92
clang::Sema::ActOnMemInitializers(clang::Decl*, clang::SourceLocation,
clang::CXXCtorInitializer**, unsigned int, bool) + 2994
8  clang             0x00000000007d7402
clang::Parser::ParseConstructorInitializer(clang::Decl*) + 930
9  clang             0x00000000007c250c
clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 908
10 clang             0x00000000007bff50
clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 144
11 clang             0x00000000007da57c
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 1724
12 clang             0x00000000007db681
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 3729
13 clang             0x00000000007c95e3
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 3395
14 clang             0x00000000007bb5df
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 95
15 clang             0x00000000007bba8a
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 522
16 clang             0x00000000007bec7a
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1546
17 clang             0x00000000007bedc6
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 134
18 clang             0x000000000079be0d clang::ParseAST(clang::Sema&, bool) +
269
19 clang             0x000000000066b3d4 clang::CodeGenAction::ExecuteAction() +
68
20 clang             0x0000000000557533
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
21 clang             0x000000000052eb34
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1268
22 clang             0x00000000005259eb cc1_main(char const**, char const**,
char const*, void*) + 683
23 clang             0x000000000052d987 main + 6295
24 libc.so.6         0x00007f254031bc4d __libc_start_main + 253
25 clang             0x0000000000523eb9
Stack dump:
0.      Program arguments:
/home/tla/Projects/llvm/build/Release+Asserts/bin/clang -cc1 -fsyntax-only -x
c++ -O3 -emit-llvm 
1.      <stdin>:1:48: current parser token '{'
2.      <stdin>:1:1: parsing struct/union/class body 'S'
Aborted

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

From bugzilla-daemon at llvm.org  Sat May  7 08:11:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 08:11:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9865] New: Sema: Can't find templated cast operator
Message-ID: <bug-9865-206@http.llvm.org/bugs/>

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

           Summary: Sema: Can't find templated cast operator
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: waste.manager at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Attached is short test file which compiles fine with g++, but the trunk
version r131043 of clang failed to compile it.

linux-olg4:~$ src/build-llvm/bin/clang++ ./a.cpp -o a
clang-3.0: /home/pbn/src/llvm/tools/clang/lib/Sema/SemaOverload.cpp:8371:
clang::ExprResult clang::Sema::CreateOverloadedBinOp(clang::SourceLocation,
unsigned int, const clang::UnresolvedSetImpl&, clang::Expr*, clang::Expr*):
Assertion `Result.isInvalid() && "C++ binary operator overloading is missing
candidates!"' failed.
Stack dump:
0.      Program arguments: /home/pbn/src/build-llvm/bin/clang-3.0 -cc1 -triple
i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name a.cpp
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -momit-leaf-frame-pointer -resource-dir
/home/pbn/src/build-llvm/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit
19 -fmessage-length 211 -fcxx-exceptions -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-3RcZDb.o -x c++
./a.cpp 
1.      ./a.cpp:67:39: current parser token ';'
2.      ./a.cpp:66:1: parsing function body 'main'
3.      ./a.cpp:66:1: in compound statement ('{}')
clang-3: error: unable to execute command: Aborted
clang-3: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Sat May  7 10:52:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 10:52:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9866] New: Generated code causes segfault
Message-ID: <bug-9866-206@http.llvm.org/bugs/>

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

           Summary: Generated code causes segfault
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: navneet.dalal at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6554)
 --> (http://llvm.org/bugs/attachment.cgi?id=6554)
Compile the code using Clang 2.9. Need to specify -I<eigen library header path>

The following code causes segfault in the generated executable when compiled
with Clang 2.8/2.9. Though it compiles & works fine with g++ & llvm-g++.

You would need Eigen 3.0.0 library to compile. 
http://eigen.tuxfamily.org/index.php?title=Main_Page

If you uncomment the #define in the code, the executable works 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  Sat May  7 11:30:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 11:30:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9867] New: Optimization introduces intrinsics and
 they are not lowered.
Message-ID: <bug-9867-206@http.llvm.org/bugs/>

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

           Summary: Optimization introduces intrinsics and they are not
                    lowered.
           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: ofv at wanadoo.es
                CC: llvmbugs at cs.uiuc.edu


Starting with the attached file, execute this sequence of operations:

llvm-as code.llvm -o code.bc

opt -O2 code.bc -o code.opt.bc

llvm-dis code.opt.bc -o code.opt.llvm

code.opt.llvm contains a call to llvm.trap, which was not present on the
original code. I have more instances where intrinsics are introduced by
otpimization (not only llvm.trap).

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

From bugzilla-daemon at llvm.org  Sat May  7 13:58:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 13:58:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9863] gcc front-end compilation: getting error:
 exec: -Q: invalid option
In-Reply-To: <bug-9863-206@http.llvm.org/bugs/>
References: <bug-9863-206@http.llvm.org/bugs/>
Message-ID: <20110507185802.9F2122A6C12C@llvm.org>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asl at math.spbu.ru
         Resolution|WONTFIX                     |INVALID

--- Comment #2 from Anton Korobeynikov <asl at math.spbu.ru> 2011-05-07 13:58:02 CDT ---
The problem here is that there are no cross-tools available in your path (e.g.
you don't have i686-pc-linux-gnu-as, etc. around)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  7 14:12:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 14:12:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9868] New: Unimplemented destructor in Operator.h
 causes issues with GCC 4.6 and C++0x
Message-ID: <bug-9868-206@http.llvm.org/bugs/>

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

           Summary: Unimplemented destructor in Operator.h causes issues
                    with GCC 4.6 and C++0x
           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: a.pignotti at sssup.it
                CC: llvmbugs at cs.uiuc.edu


--------------
/// ConcreteOperator - A helper template for defining operators for individual
/// opcodes.
template<typename SuperClass, unsigned Opc>
class ConcreteOperator : public SuperClass {
  ~ConcreteOperator(); // DO NOT IMPLEMENT
public:
  static inline bool classof(const ConcreteOperator<SuperClass, Opc> *) {
    return true;
  }
  static inline bool classof(const Instruction *I) {
    return I->getOpcode() == Opc;
  }
  static inline bool classof(const ConstantExpr *CE) {
    return CE->getOpcode() == Opc;
  }
  static inline bool classof(const Value *V) {
    return (isa<Instruction>(V) && classof(cast<Instruction>(V))) ||
           (isa<ConstantExpr>(V) && classof(cast<ConstantExpr>(V)));
  }
};
----------------

When including the Operator.h file and compiling with g++ 4.6 and C++0x is
enabled (--std=c++0x) the not implemented destructor causes a compiler error.
Commenting out the line fixes the issue, but I'm not sure if this is the right
fix. Anyway it's not clear to me what's the rationale behind such 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  Sat May  7 14:38:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 14:38:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9869] New: Operator.h incompatibility with GCC 4.6
 in C++0x mode
Message-ID: <bug-9869-206@http.llvm.org/bugs/>

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

           Summary: Operator.h incompatibility with GCC 4.6 in C++0x mode
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: foutrelis at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

After upgrading to LLVM 2.9 and GCC 4.6 (on Arch Linux), Lightspark can no
longer be built. The problem seems to originate in Operator.h, when the
compilation uses -std=c++0x.

I have also tested LLVM 2.9 + GCC 4.5 as well as LLVM 2.8 + GCC 4.6. Both work
fine for compiling Lightspark. It's just the LLVM 2.9 + GCC 4.6 combination
that has this problem.

The errors I'm seeing all look like this:

/usr/include/llvm/Operator.h:188:7: error: deleted function ?virtual
llvm::AddOperator::~AddOperator()?
/usr/include/llvm/Operator.h:171:3: error: overriding non-deleted function
?llvm::ConcreteOperator<SuperClass, Opc>::~ConcreteOperator() [with SuperClass
= llvm::OverflowingBinaryOperator, unsigned int Opc = 8u]?
/usr/include/llvm/Operator.h:188:7: error: ?virtual
llvm::AddOperator::~AddOperator()? is implicitly deleted because the default
definition would be ill-formed:
/usr/include/llvm/Operator.h:171:3: error: ?llvm::ConcreteOperator<SuperClass,
Opc>::~ConcreteOperator() [with SuperClass = llvm::OverflowingBinaryOperator,
unsigned int Opc = 8u]? is private
/usr/include/llvm/Operator.h:188:7: error: within this context

The errors reference the deconstructors of other operators as well.

The complete list is:

llvm::AddOperator::~AddOperator()
llvm::SubOperator::~SubOperator()
llvm::MulOperator::~MulOperator()
llvm::ShlOperator::~ShlOperator()
llvm::SDivOperator::~SDivOperator()
llvm::UDivOperator::~UDivOperator()
llvm::AShrOperator::~AShrOperator()
llvm::LShrOperator::~LShrOperator()
llvm::GEPOperator::~GEPOperator()

You should be able to reproduce this issue with the attached test.cpp by
running 'g++ test.cpp -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-std=c++0x'.

Let me know if I need to provide further information.

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

From bugzilla-daemon at llvm.org  Sat May  7 14:47:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 14:47:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9868] Unimplemented destructor in Operator.h causes
 issues with GCC 4.6 and C++0x
In-Reply-To: <bug-9868-206@http.llvm.org/bugs/>
References: <bug-9868-206@http.llvm.org/bugs/>
Message-ID: <20110507194754.989392A6C12C@llvm.org>

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

Alessandro Pignotti <a.pignotti at sssup.it> changed:

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

--- Comment #1 from Alessandro Pignotti <a.pignotti at sssup.it> 2011-05-07 14:47:54 CDT ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  7 18:19:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 18:19:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9870] New: Clang and C++ 4.5.2
Message-ID: <bug-9870-206@http.llvm.org/bugs/>

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

           Summary: Clang and C++ 4.5.2
           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: mnouh3 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


For some reason clang isn't finding the header files with 4.5.2. It only goes
to version 4.4.X.


Will work:
$ clang++ -I/usr/include/c++/4.5.2
-I/usr/include/c++/4.5.2/x86_64-linux-gnu test.cpp



mnouh at mnouh:~/Desktop$ clang++ -v -fno-use-cxa-atexit main.cpp
clang version 2.8 (branches/release_28)
Target: x86_64-pc-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -S -disable-free
-disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static
-mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64
-target-linker-version 2.21.0.20110216 -v -resource-dir /usr/lib/clang/2.8
-ferror-limit 19 -fmessage-length 80 -fexceptions -fno-use-cxa-atexit
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-541mvU.s
-x c++ main.cpp
clang -cc1 version 2.8 based upon llvm 2.8rc hosted on x86_64-pc-linux-gnu
ignoring nonexistent directory "/usr/include/c++/4.4"
ignoring nonexistent directory "/usr/include/c++/4.4/x86_64-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.4/backward"
ignoring nonexistent directory "/usr/include/c++/4.4"
ignoring nonexistent directory "/usr/include/c++/4.4/i486-linux-gnu/64"
ignoring nonexistent directory "/usr/include/c++/4.4/backward"
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.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"
ignoring nonexistent directory "/usr/include/c++/4.4/i586-suse-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4/backward"
ignoring nonexistent directory "/usr/include/c++/4.4"
ignoring nonexistent directory "/usr/include/c++/4.4/x86_64-suse-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4/backward"
ignoring nonexistent directory "/usr/include/c++/4.3.1"
ignoring nonexistent directory "/usr/include/c++/4.3.1/i686-pc-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.3.1/backward"
ignoring nonexistent directory "/usr/include/c++/4.3.1"
ignoring nonexistent directory
"/usr/include/c++/4.3.1/x86_64-unknown-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.3.1/backward"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/i686-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/i686-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/backward"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/backward"
ignoring nonexistent directory
"/usr/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"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/clang/2.8/include
 /usr/include
End of search list.
main.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^
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  Sat May  7 21:00:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  7 May 2011 21:00:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9869] Operator.h incompatibility with GCC 4.6 in
	C++0x mode
In-Reply-To: <bug-9869-206@http.llvm.org/bugs/>
References: <bug-9869-206@http.llvm.org/bugs/>
Message-ID: <20110508020002.1C92D2A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #6 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-07 21:00:01 CDT ---
r131062.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  8 00:19:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  8 May 2011 00:19:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9866] Generated code causes segfault
In-Reply-To: <bug-9866-206@http.llvm.org/bugs/>
References: <bug-9866-206@http.llvm.org/bugs/>
Message-ID: <20110508051927.7F9ED2A6C124@llvm.org>

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

ND <navneet.dalal at gmail.com> changed:

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

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

From bugzilla-daemon at llvm.org  Sun May  8 07:28:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  8 May 2011 07:28:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9867] Optimization introduces intrinsics and they
 are not lowered.
In-Reply-To: <bug-9867-206@http.llvm.org/bugs/>
References: <bug-9867-206@http.llvm.org/bugs/>
Message-ID: <20110508122831.899BA2A6C12C@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

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

--- Comment #13 from ?scar Fuentes <ofv at wanadoo.es> 2011-05-08 07:28:30 CDT ---
It works now.

Apparently the problem was caused by my compiler running an incorrect series of
passes when optimizations are enabled. This is the code I was using, taken from
a past incantation of lli (or opt, I'm not sure):

    if( optimizationLevel > 0 ) {
      PassManager Passes;
      Passes.add( new TargetData(M) );
      FunctionPassManager *FPasses = new FunctionPassManager(M);
      FPasses->add( new TargetData(M) );

      createStandardFunctionPasses(FPasses, optimizationLevel);
      llvm::Pass *InliningPass = createFunctionInliningPass();
      createStandardModulePasses(&Passes, optimizationLevel,
                                 /*OptimizeSize=*/ false,
                                 /*UnitAtATime=*/ true,
                                 /*UnrollLoops=*/ true,
                                 /*SimplifyLibCalls=*/ true,
                                 /*HaveExceptions=*/ false,
                                 InliningPass);

      FPasses->doInitialization();
      for (Module::iterator I = M->begin(), E = M->end(); I != E; ++I)
        FPasses->run(*I);
      FPasses->doFinalization();

      Passes.run(*M);
    }

After replacing that code with a call to builder::setOptLevel the optimized
LLVM bitcode no longer contains calls to llvm.trap. That was consistent with
what I was told on irc: on the JIT, after running the passes the right way, no
intrinsics are left on the code.

What is still unresolved is whether the JIT handles occurrences of llvm.trap or
barfs at it. Eli, if you want to investigate this further, please reopen the
bug and provide instructions about what to do for feeding you with more 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  Sun May  8 08:08:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  8 May 2011 08:08:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9871] New: clang crashes in register allocator on
	PPC
Message-ID: <bug-9871-206@http.llvm.org/bugs/>

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

           Summary: clang crashes in register allocator on PPC
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: js-llvm-bugzilla at webkeks.org
                CC: llvmbugs at cs.uiuc.edu


Assertion failed: (Stage < RS_Spill && "Cannot allocate after spilling"),
function selectOrSplit, file RegAllocGreedy.cpp, line 1379.
0  clang             0x01918c8c llvm::SmallVectorTemplateBase<llvm_regmatch_t,
false>::grow(unsigned long) + 908
1  clang             0x01919e30 llvm::SmallVectorTemplateBase<llvm_regmatch_t,
false>::grow(unsigned long) + 5424
2  libSystem.B.dylib 0x973e79fc _sigtramp + 68
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
powerpc-apple-darwin9.8.0 -S -disable-free -main-file-name OFHTTPRequest.m
-pic-level 2 -mdisable-fp-elim -target-linker-version 85.2.1 -coverage-file
/var/folders/r6/r6-A-X9iFjCgOaLQUX8VME+++TI/-Tmp-/cc-duk43Z.s -resource-dir
/usr/local/bin/../lib/clang/3.0 -D PIC -I . -I .. -I exceptions -O2 -Wall
-Wwrite-strings -Wcast-align -Wpointer-arith -Werror -std=gnu99 -fconst-strings
-fno-dwarf2-cfi-asm -fconstant-string-class OFConstantString -ferror-limit 19
-fmessage-length 146 -fblocks -fobjc-exceptions -fexceptions
-fno-constant-cfstrings -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/r6/r6-A-X9iFjCgOaLQUX8VME+++TI/-Tmp-/cc-duk43Z.s -x objective-c
OFHTTPRequest.m 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'OFHTTPRequest.m'.
4.      Running pass 'Greedy Register Allocator' on function
'@"\01-[OFHTTPRequest performWithRedirects:]"'
clang: error: unable to execute command: Trace/BPT trap
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

This happens in countless files. I tried compiling the failing files with gcc
and the rest with clang until I had to give up because 30% of all files failed
with this assertion.

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

From bugzilla-daemon at llvm.org  Sun May  8 11:17:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  8 May 2011 11:17:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9872] New: Assertion failed: (Reg && "Invalid
 SubReg for physical register")
Message-ID: <bug-9872-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (Reg && "Invalid SubReg for physical
                    register")
           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=6560)
 --> (http://llvm.org/bugs/attachment.cgi?id=6560)
bugpoint-reduced-blocks.bc

Recent regressin building the aic7xxx/ahc FreeBSD driver.

llvm/clang trunk r131065.

% llc bugpoint-reduced-blocks.bc 
Assertion failed: (Reg && "Invalid SubReg for physical register"), function
substPhysReg, file
/data/buildslave/freebsd-clang-i386/src-llvm/lib/CodeGen/MachineInstr.cpp, line
128.
Stack dump:
0.    Program arguments:
/data/buildslave/freebsd-clang-i386/obj/obj-llvm.2/Release+Asserts/bin/llc
bugpoint-reduced-blocks.bc 
1.    Running pass 'Function Pass Manager' on module
'bugpoint-reduced-blocks.bc'.
2.    Running pass 'Greedy Register Allocator' on function '@ahc_handle_seqint'
Abort (core dumped)

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

From bugzilla-daemon at llvm.org  Sun May  8 12:28:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  8 May 2011 12:28:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9873] New: clang -MMD is different than GCC
 regarding pragma GCC system_header
Message-ID: <bug-9873-206@http.llvm.org/bugs/>

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

           Summary: clang -MMD is different than GCC regarding pragma GCC
                    system_header
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: adrianosf at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


With GCC, "#pragma GCC system_header" does not interfere with dependencies
emitted by -MMD.

clang suppress header files included from files using this pragma.

I think clang should emulate this *GCC* pragma as GCC 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  Sun May  8 13:04:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  8 May 2011 13:04:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9873] clang -MMD is different than GCC regarding
 pragma GCC system_header
In-Reply-To: <bug-9873-206@http.llvm.org/bugs/>
References: <bug-9873-206@http.llvm.org/bugs/>
Message-ID: <20110508180444.010C52A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-08 13:04:43 CDT ---
Marking invalid per reporter's request.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May  8 14:21:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  8 May 2011 14:21:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9872] Assertion failed: (Reg && "Invalid SubReg for
 physical register")
In-Reply-To: <bug-9872-206@http.llvm.org/bugs/>
References: <bug-9872-206@http.llvm.org/bugs/>
Message-ID: <20110508192159.186D62A6C12C@llvm.org>

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

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

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

--- Comment #2 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-08 14:21:58 CDT ---
Fixed in r131073, 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 May  8 22:39:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  8 May 2011 22:39:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9874] New: clang static analyzer erroneously
 implicates a ternary conditional not taken
Message-ID: <bug-9874-206@http.llvm.org/bugs/>

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

           Summary: clang static analyzer erroneously implicates a ternary
                    conditional not taken
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: austinenglish at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The particular implicated branch of the ternary expression is not reached, so
the warning doesn't make sense.

../../../wine.git/dlls/wininet/http.c:1421:21: error: implicit conversion from
'int' to 'signed char' changes value from 256 to 0
[-Werror,-Wconstant-conversion]
    CH(250),CH(251),CH(252),CH(253),CH(254),CH(255),
                    ^~~~~~~
../../../wine.git/dlls/wininet/http.c:1392:45: note: instantiated from:
               ((x) >= '0' && (x) <= '9') ? (x) - '0' + 52 : \
                                          ~ ^~~~~~~~~~~~~~
../../../wine.git/dlls/wininet/http.c:1421:29: error: implicit conversion from
'int' to 'signed char' changes value from 257 to 1
[-Werror,-Wconstant-conversion]
    CH(250),CH(251),CH(252),CH(253),CH(254),CH(255),
                            ^~~~~~~
../../../wine.git/dlls/wininet/http.c:1392:45: note: instantiated from:
               ((x) >= '0' && (x) <= '9') ? (x) - '0' + 52 : \
                                          ~ ^~~~~~~~~~~~~~
../../../wine.git/dlls/wininet/http.c:1421:37: error: implicit conversion from
'int' to 'signed char' changes value from 258 to 2
[-Werror,-Wconstant-conversion]
    CH(250),CH(251),CH(252),CH(253),CH(254),CH(255),
                                    ^~~~~~~
../../../wine.git/dlls/wininet/http.c:1392:45: note: instantiated from:
               ((x) >= '0' && (x) <= '9') ? (x) - '0' + 52 : \
                                          ~ ^~~~~~~~~~~~~~
../../../wine.git/dlls/wininet/http.c:1421:45: error: implicit conversion from
'int' to 'signed char' changes value from 259 to 3
[-Werror,-Wconstant-conversion]
    CH(250),CH(251),CH(252),CH(253),CH(254),CH(255),
                                            ^~~~~~~
../../../wine.git/dlls/wininet/http.c:1392:45: note: instantiated from:
               ((x) >= '0' && (x) <= '9') ? (x) - '0' + 52 : \
                                          ~ ^~~~~~~~~~~~~~
4 errors generated.
make: *** [http.o] Error 1
make: Leaving directory `/home/austin/wine32-clang/dlls/wininet'

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

From bugzilla-daemon at llvm.org  Mon May  9 06:20:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 06:20:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9727] -O2 -ftree-vectorize
 -fplugin-arg-dragonegg-enable-gcc-optzns fails to compile utils.c
In-Reply-To: <bug-9727-206@http.llvm.org/bugs/>
References: <bug-9727-206@http.llvm.org/bugs/>
Message-ID: <20110509112058.6E2632A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-05-09 06:20:57 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110509/120554.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 May  9 09:07:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 09:07:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9875] New: getVisualStudioDir() brokes system
	environment
Message-ID: <bug-9875-206@http.llvm.org/bugs/>

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

           Summary: getVisualStudioDir() brokes system environment
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rmorylev at gmail.com
                CC: llvmbugs at cs.uiuc.edu


getVisualStudioDir() in Frontend/InitHeaderSearch.cpp modifies the string
returned by getenv().
So, before getVisualStudioDir() call I have:
getenv("VS90COMNTOOLS") = "C:\Program Files\Microsoft Visual Studio
9.0\Common7\Tools\"
and after call I always have:
getenv("VS90COMNTOOLS") = "C:\Program Files\Microsoft Visual Studio 9.0"

Compiler: Visual C++ 2008

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

From bugzilla-daemon at llvm.org  Mon May  9 09:29:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 09:29:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9876] New: class in nested namespace with same name
 suddenly ambigous when compiling with Objective-C++
Message-ID: <bug-9876-206@http.llvm.org/bugs/>

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

           Summary: class in nested namespace with same name suddenly
                    ambigous when compiling with Objective-C++
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code:

namespace A {
    namespace Class {
        class Class { void doIt(); };
    }
}


using namespace A::Class;

void Class::doIt()
{
}


int main(int, char**)
{
}


compiles perfectly using clang in C++ mode. In Objective-C++ mode however, the
following errors are generated:

/opt/bin/clang -x objective-c++ clang.cpp
clang.cpp:10:6: error: expected a class or namespace
void Class::doIt()
     ^
clang.cpp:10:6: error: reference to 'Class' is ambiguous
void Class::doIt()
     ^
note: candidate found by name lookup is 'Class'
clang.cpp:3:9: note: candidate found by name lookup is 'A::Class::Class'
                class Class { void doIt(); };
                      ^
2 errors generated.


It seems as if in Objective-C++ mode, clang is including a "using namespace A"
(to use the using declarations parent namespace), therefore making the "Class"
symbol ambigous.


My clang version:

/opt/bin/clang --version
clang version 3.0 (trunk 131082)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

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

From bugzilla-daemon at llvm.org  Mon May  9 09:51:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 09:51:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9877] New: cannot define member of explicitly
 specialized member class
Message-ID: <bug-9877-206@http.llvm.org/bugs/>

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

           Summary: cannot define member of explicitly specialized member
                    class
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zilla at kayari.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


template<int>
struct X
{
    struct Y;
};

template<> struct X<0>::Y { static const int Z = 1; };

const int X<0>::Y::Z;

This is well-formed, see [temp.expl.spec]/5 and the accompanying example
(modified by core DR 531, see N3262)

The definition is also rejected with "template<>" (which is correct):
  template<> const int X<0>::Y::Z;
so there seems to be no way to provide a definition of X<0>::Y::Z

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

From bugzilla-daemon at llvm.org  Mon May  9 10:11:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 10:11:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9878] New: Constructor's/Destructor's priorities
	are ignored
Message-ID: <bug-9878-206@http.llvm.org/bugs/>

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

           Summary: Constructor's/Destructor's priorities are ignored
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tim.nieradzik at gmx.de
                CC: llvmbugs at cs.uiuc.edu


GCC supports specifying priorities for constructors and destructors:

"You may provide an optional integer priority to control the order in which
constructor and destructor functions are run. A constructor with a smaller
priority number runs before a constructor with a larger priority number; the
opposite relationship holds for destructors. So, if you have a constructor that
allocates a resource and a destructor that deallocates the same resource, both
functions typically have the same priority. [...]"

(Source: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html)

Clang, however, ignores the priorities. Therefore, the attached example prints:
ctor2()
ctor1()
ctor0()
main()
dtor0()
dtor1()
dtor2()

Whereas the correct output would have been:
ctor0()
ctor1()
ctor2()
main()
dtor2()
dtor1()
dtor0()

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

From bugzilla-daemon at llvm.org  Mon May  9 10:16:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 10:16:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9878] Constructor's/Destructor's priorities are
	ignored
In-Reply-To: <bug-9878-206@http.llvm.org/bugs/>
References: <bug-9878-206@http.llvm.org/bugs/>
Message-ID: <20110509151655.83EEF2A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-05-09 10:16:55 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon May  9 11:44:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 11:44:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9879] New: SelectionDAGBuilder does not preserve
 debug information attached to phi nodes
Message-ID: <bug-9879-206@http.llvm.org/bugs/>

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

           Summary: SelectionDAGBuilder does not preserve debug
                    information attached to phi nodes
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6562)
 --> (http://llvm.org/bugs/attachment.cgi?id=6562)
bitcode file that causes debug information to get dropped.

The attached bitcode file looses debug information when it is run through any
backend. The variables gid and tid do not show up in the dwarf information and
are dropped in the function visitIntrinsicCall when visiting a
Instrinsic::dbg_value node that is referencing a PHINode.

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

From bugzilla-daemon at llvm.org  Mon May  9 12:32:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 12:32:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9880] New: Regression: clang crashes with
 "HasMemberXXX" template when return types are outside the template
Message-ID: <bug-9880-206@http.llvm.org/bugs/>

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

           Summary: Regression: clang crashes with "HasMemberXXX" template
                    when return types are outside the template
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

The attached code is used to check if a class has a member "luaIndex" via
SFINAE and the helper template "HasIndexMetamethod".

When NO_CRASH_PLEASE is undefined, the structs "no_tag" and "yes" tag are
outside "HasIndexMetamethod", and clang crashes with an assertion (see attached
log).

When NO_CRASH_PLEASE is defined, the two structs are inside
"HasIndexMetamethod", and clang does not crash.

The code used to work in clang trunk from two weeks ago (25th May around noon).
Unfortunately, I do not remember the revision anymore.

My clang version: /opt/bin/clang -std=c++0x --version
clang version 3.0 (trunk 131082)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

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

From bugzilla-daemon at llvm.org  Mon May  9 12:35:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 12:35:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9862] clang can't link with -g on darwin if
 POSIXLY_CORRECT environmental is set
In-Reply-To: <bug-9862-206@http.llvm.org/bugs/>
References: <bug-9862-206@http.llvm.org/bugs/>
Message-ID: <20110509173504.16ED02A6C124@llvm.org>

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

Daniel Dunbar <daniel at zuster.org> changed:

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

--- Comment #4 from Daniel Dunbar <daniel at zuster.org> 2011-05-09 12:35:03 CDT ---
Fixed here:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=131084

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

From bugzilla-daemon at llvm.org  Mon May  9 12:43:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 12:43:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9881] New: 'make check' fails by default when
 configured with --enable-shared
Message-ID: <bug-9881-206@http.llvm.org/bugs/>

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

           Summary: 'make check' fails by default when configured with
                    --enable-shared
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nobled at dreamwidth.org
                CC: llvmbugs at cs.uiuc.edu


All the tests under 'make check' fail with a message like this:

.../Release+Asserts/bin/opt: error while loading shared libraries:
libLLVM-3.0svn.so: cannot open shared object file: No such file or directory

It only works as intended if you copy libLLVM-3.0svn.so into the system lib
path, or set LD_LIBRARY_PATH manually:

LD_LIBRARY_PATH=<top_builddir>/Release+Asserts/lib make check

Should the build scripts do that kind of thing themselves? It should also
prevent accidentally picking up an outdated, incompatible shared lib that might
have been `make install`d from a previous build, which would give 'missing
symbol' 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  Mon May  9 13:39:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 13:39:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6731] alpha: ICE at
	llvm-gcc4.2-2.6.source/gcc/libgcov.c:817
In-Reply-To: <bug-6731-206@http.llvm.org/bugs/>
References: <bug-6731-206@http.llvm.org/bugs/>
Message-ID: <20110509183911.29E672A6C124@llvm.org>

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

Matt Turner <mattst88 at gmail.com> changed:

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

--- Comment #5 from Matt Turner <mattst88 at gmail.com> 2011-05-09 13:39:10 CDT ---
Can no longer reproduce. 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 May  9 15:46:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 15:46:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9882] New: noexcept sometimes returns unexpected
	value
Message-ID: <bug-9882-206@http.llvm.org/bugs/>

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

           Summary: noexcept sometimes returns unexpected value
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


#include <iostream>

template <class T, T v>
struct integral_constant
{
    static const T value1 = v;
};

template <class T>
T&& declval() noexcept;

template <class T, class U>
struct is_nothrow_assignable
    : public integral_constant<bool, noexcept(declval<T>() = declval<U>())>
{
    static const bool value2 = noexcept(declval<T>() = declval<U>());
};

int main()
{
    std::cout << is_nothrow_assignable<int&, int&>::value1 << '\n';
    std::cout << is_nothrow_assignable<int&, int&>::value2 << '\n';
}

I'm getting:

0
1

I'm expecting:

1
1

It seems like the noexcept wrongly evaluates to false when used in specifying
the base class.

With this fixed, I think I can implement the nothrow type traits without
compiler support as long as the associated non-nothrow type traits are working.

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

From bugzilla-daemon at llvm.org  Mon May  9 15:46:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 15:46:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9880] Regression: clang crashes with "HasMemberXXX"
 template when return types are outside the template
In-Reply-To: <bug-9880-206@http.llvm.org/bugs/>
References: <bug-9880-206@http.llvm.org/bugs/>
Message-ID: <20110509204650.9AD272A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-05-09 15:46:50 CDT ---
Fixed in Clang r131099.

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

From bugzilla-daemon at llvm.org  Mon May  9 16:47:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 16:47:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8151] Ambiguous name lookup compiling error
In-Reply-To: <bug-8151-206@http.llvm.org/bugs/>
References: <bug-8151-206@http.llvm.org/bugs/>
Message-ID: <20110509214726.58C262A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-09 16:47:25 CDT ---
Fixed in Clang r131102.

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

From bugzilla-daemon at llvm.org  Mon May  9 17:32:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 17:32:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8495] [IRGen] Assertion "Instruction does not
 dominate all uses!"
In-Reply-To: <bug-8495-206@http.llvm.org/bugs/>
References: <bug-8495-206@http.llvm.org/bugs/>
Message-ID: <20110509223258.EAD942A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-05-09 17:32:57 CDT ---
I can't reproduce this with trunk. If it's still crashing for you with Clang
trunk, please re-open!

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

From bugzilla-daemon at llvm.org  Mon May  9 17:36:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 17:36:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8792] using namespace creates ambiguity when there
	isn't.
In-Reply-To: <bug-8792-206@http.llvm.org/bugs/>
References: <bug-8792-206@http.llvm.org/bugs/>
Message-ID: <20110509223602.BF0022A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-09 17:36:02 CDT ---
Fixed this in Clang r130810.

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

From bugzilla-daemon at llvm.org  Mon May  9 17:37:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 17:37:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8793] Clang compiles member function call with
	missing ()
In-Reply-To: <bug-8793-206@http.llvm.org/bugs/>
References: <bug-8793-206@http.llvm.org/bugs/>
Message-ID: <20110509223711.3BE432A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-05-09 17:37:10 CDT ---
John fixed this in Clang r130239.

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

From bugzilla-daemon at llvm.org  Mon May  9 17:37:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 17:37:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9493] Dwarf relocation missing in ARM assembly
	output
In-Reply-To: <bug-9493-206@http.llvm.org/bugs/>
References: <bug-9493-206@http.llvm.org/bugs/>
Message-ID: <20110509223718.2A5132A6C130@llvm.org>

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

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

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

--- Comment #6 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-05-09 17:37:17 CDT ---
This was 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 May  9 17:50:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 17:50:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9649] empty.o breaks dwarfdump
In-Reply-To: <bug-9649-206@http.llvm.org/bugs/>
References: <bug-9649-206@http.llvm.org/bugs/>
Message-ID: <20110509225047.959BE2A6C12D@llvm.org>

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

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

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

--- Comment #7 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-05-09 17:50:46 CDT ---
This was fixed in 130846.

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

From bugzilla-daemon at llvm.org  Mon May  9 18:06:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 18:06:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8326] const union member in template class gives
	invalid error
In-Reply-To: <bug-8326-206@http.llvm.org/bugs/>
References: <bug-8326-206@http.llvm.org/bugs/>
Message-ID: <20110509230605.1329F2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-09 18:06:04 CDT ---
I think that, technically, this code is ill-formed, since it isn't of the form

  union { member-specification };

that declares an anonymous union. 

However, we should accept this code as an extension.

Fixed in Clang r131109.

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

From bugzilla-daemon at llvm.org  Mon May  9 18:14:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 18:14:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9208] clang fails to reject invalid typeid
 expression and so crashes later on
In-Reply-To: <bug-9208-206@http.llvm.org/bugs/>
References: <bug-9208-206@http.llvm.org/bugs/>
Message-ID: <20110509231453.C222B2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #7 from Douglas Gregor <dgregor at apple.com> 2011-05-09 18:14:52 CDT ---
Clang trunk is correctly accepting all 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 May  9 18:36:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 18:36:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9536] [gcc compat] clang rejects static data member
 in unnamed class
In-Reply-To: <bug-9536-206@http.llvm.org/bugs/>
References: <bug-9536-206@http.llvm.org/bugs/>
Message-ID: <20110509233658.586BA2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-05-09 18:36:57 CDT ---
And how would we mangle that name, if we had to? I don't think we should
support this GCC extension.

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

From bugzilla-daemon at llvm.org  Mon May  9 18:50:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 18:50:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9683] Assert generated when clang GEP's into nested
 unnamed structs
In-Reply-To: <bug-9683-206@http.llvm.org/bugs/>
References: <bug-9683-206@http.llvm.org/bugs/>
Message-ID: <20110509235017.429C22A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-09 18:50:16 CDT ---
I've not able to reproduce this. If it is still an issue with top-of-tree
Clang, please re-open.

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

From bugzilla-daemon at llvm.org  Mon May  9 23:45:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  9 May 2011 23:45:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9883] New: Assertion `valid() && "Cannot access
 invalid iterator"' failed.
Message-ID: <bug-9883-206@http.llvm.org/bugs/>

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

           Summary: Assertion `valid() && "Cannot access invalid
                    iterator"' 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 gamow tmp022]$ clang -O2 small.c -c -w

clang:
/uusoc/exports/scratch/regehr/z/compiler-build/llvm-r131121/include/llvm/ADT/IntervalMap.h:1315:
KeyT& llvm::IntervalMap<KeyT, ValT, N, Traits>::const_iterator::unsafeStop()
const [with KeyT = llvm::SlotIndex, ValT = llvm::LiveInterval*, unsigned int N
= 8u, Traits = llvm::IntervalMapInfo<llvm::SlotIndex>]: Assertion `valid() &&
"Cannot access invalid iterator"' failed.
0  clang           0x00000000018e525f
1  clang           0x00000000018e74d2
2  libpthread.so.0 0x00007ffff7bcf8f0
3  libc.so.6       0x00007ffff6ebea75 gsignal + 53
4  libc.so.6       0x00007ffff6ec25c0 abort + 384
5  libc.so.6       0x00007ffff6eb7941 __assert_fail + 241
6  clang           0x0000000001581ecf
llvm::RegAllocBase::checkPhysRegInterference(llvm::LiveInterval&, unsigned int)
+ 463
7  clang           0x0000000001483c8b
8  clang           0x00000000014897d4
9  clang           0x000000000148aca1
10 clang           0x0000000001582ea2 llvm::RegAllocBase::allocatePhysRegs() +
594
11 clang           0x0000000001484586
12 clang           0x000000000183287b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 587
13 clang           0x000000000183297b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
14 clang           0x0000000001832377
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
15 clang           0x000000000183250b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
16 clang           0x00000000007c843e
17 clang           0x00000000007c906d
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 189
18 clang           0x00000000007c5a5b
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
19 clang           0x00000000008f724d clang::ParseAST(clang::Sema&, bool) + 413
20 clang           0x00000000007c4da4 clang::CodeGenAction::ExecuteAction() +
68
21 clang           0x00000000006b0cc3
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
22 clang           0x0000000000688214
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1268
23 clang           0x000000000067f0cb cc1_main(char const**, char const**, char
const*, void*) + 683
24 clang           0x0000000000687067 main + 6295
25 libc.so.6       0x00007ffff6ea9c4d __libc_start_main + 253
26 clang           0x000000000067d599
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r131121-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -coverage-file small.o -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r131121-install/bin/../lib/clang/3.0
-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.    Code generation
3.    Running pass 'Function Pass Manager' on module 'small.c'.
4.    Running pass 'Greedy Register Allocator' on function '@func_1'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

[regehr at gamow tmp022]$ clang -v

clang version 3.0 (trunk 131121)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[regehr at gamow tmp022]$ cat small.c 


static char
safe_2 (char si1, char si2)
{
  return 0 ? 0 : si1 + 1;
}

struct S0
{
  long f0;
  int f1;
  unsigned f2;
  unsigned f3;
  long f4;
  signed f5:1 ? 32 : 0;
  short f6;
  unsigned f9;
};
int g_2[][0][1] = {
};

int g_30;
int **g_39;
struct S0 g_103 = {
};

int *volatile g_107;
int *g_161;
struct S0 g_183[][0][1] = {
};

static struct S0 *g_244 = &g_183[0][1][0];
static int g_390;
int *volatile g_397;
static int func_12 (short, unsigned char, int **);
int **func_22 (unsigned, unsigned, short);
unsigned
func_1 (void)
{
  func_12 (0, g_2[0][0][0], func_22 (0, 0, 0)), 0;
  return 0;
}

int
func_12 (short p_13, unsigned char p_14, int **p_15)
{
  int ***l_430 = &g_39;
  int l_451;
  int l_443[0][1];
  struct S0 l_477 = {
    0, 0, 1, 1, 0, 305867, 1, 1,
  };
  if (*g_161)
    {
      for (g_30 = 0; g_30 <= 1; g_30 = safe_2 (g_30, 1))
    if (p_14)
      *g_244 = l_477;
      for (l_477.f6 = 0; l_477.f6; l_477.f6 = 1)
    {
      *g_397;
      if (p_14)
        break;
    }
    }
  else
    {
    lbl_494:*g_107;
      for (l_451 = 0; l_451 >= 0; l_451 -= 1)
    for (; l_477.f6; l_477.f6 = 1)
      {
        for (; g_390 < 1; g_390 += 1)
          **l_430 = &l_443[l_451][l_477.f6];
        if (g_103.f0)
          goto lbl_494;
        *g_244 = l_477;
      }
    }
  return 0;
}

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

From bugzilla-daemon at llvm.org  Tue May 10 01:54:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 01:54:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9884] New: Assert when derived class calls base
 class constructor with protected visibility
Message-ID: <bug-9884-206@http.llvm.org/bugs/>

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

           Summary: Assert when derived class calls base class constructor
                    with protected visibility
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: scoopr at iki.fi
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This testcase triggers a unreachable assert:


class Base {
protected:
  Base(int val);
};


class Derived : public Base {
public:
  Derived(int val);
};


Derived::Derived(int val) 
  :  Base( val )
{
}


Resulting this:
obscure:tc1 scoopr$ clang++ test.cpp -c
getSpecialMember on non-special member
UNREACHABLE executed at
/Users/scoopr/Code/ext/llvm/tools/clang/lib/Sema/SemaDecl.cpp:1521!
0  clang             0x0000000101129772
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 2514
1  clang             0x0000000101129d59
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 4025
2  libSystem.B.dylib 0x00007fff831f266a _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2095110576
4  clang             0x00000001011299c6
llvm::SmallVectorImpl<llvm_regmatch_t>::resize(unsigned int) + 3110
5  clang             0x0000000101119a62 std::_Rb_tree<std::string,
std::pair<std::string const, void*>, std::_Select1st<std::pair<std::string
const, void*> >, std::less<std::string>, std::allocator<std::pair<std::string
const, void*> > >::_M_erase(std::_Rb_tree_node<std::pair<std::string const,
void*> >*) + 1538
6  clang             0x00000001002f20f8
clang::CodeCompletionBuilder::AddOptionalChunk(clang::CodeCompletionString*) +
25656
7  clang             0x00000001002802d6
llvm::StringMapEntry<clang::IdentifierInfo*>&
llvm::StringMap<clang::IdentifierInfo*,
llvm::BumpPtrAllocator>::GetOrCreateValue<clang::IdentifierInfo*>(llvm::StringRef,
clang::IdentifierInfo*) + 9318
8  clang             0x00000001003c5619
clang::ObjCPropertyRefExpr::ObjCPropertyRefExpr(clang::ObjCPropertyDecl*,
clang::QualType, clang::ExprValueKind, clang::ExprObjectKind,
clang::SourceLocation, clang::SourceLocation, clang::QualType) + 21049
9  clang             0x0000000100337ab7 clang::VecReturnAttr*
clang::Decl::getAttr<clang::VecReturnAttr>() const + 59975
10 clang             0x0000000100336a68 clang::VecReturnAttr*
clang::Decl::getAttr<clang::VecReturnAttr>() const + 55800
11 clang             0x000000010023b707
clang::Parser::MaybeParseCXX0XAttributes(clang::Declarator&) + 27671
12 clang             0x000000010023b2b0
clang::Parser::MaybeParseCXX0XAttributes(clang::Declarator&) + 26560
13 clang             0x00000001002652ec
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 26908
14 clang             0x000000010022c023
clang::Parser::LateParsedMethodDeclaration::~LateParsedMethodDeclaration() +
22467
15 clang             0x0000000100264a6a
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 24730
16 clang             0x0000000100264c24
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 25172
17 clang             0x00000001002641fc
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 22572
18 clang             0x0000000100263868
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 20120
19 clang             0x0000000100224aed clang::MSP430InterruptAttr*
clang::Decl::getAttr<clang::MSP430InterruptAttr>() const + 749
20 clang             0x00000001002032ca
llvm::DenseMap<std::pair<clang::CXXRecordDecl const*, unsigned int>,
clang::CharUnits, llvm::DenseMapInfo<std::pair<clang::CXXRecordDecl const*,
unsigned int> >, llvm::DenseMapInfo<clang::CharUnits> >::grow(unsigned int) +
3434
21 clang             0x000000010002fb3a llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 12714
22 clang             0x0000000100009d75 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&) + 3173
23 clang             0x0000000100002821
24 clang             0x00000001000061a2 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&) + 1410
25 clang             0x0000000100001334
Stack dump:
0.    Program arguments: /opt/llvm/bin/clang -cc1 -triple
x86_64-apple-macosx10.6.7 -emit-obj -mrelax-all -disable-free -main-file-name
test.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 123.2 -coverage-file test.o
-resource-dir /opt/llvm/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit
19 -fmessage-length 80 -stack-protector 1 -fblocks -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++
test.cpp 
1.    test.cpp:17:1: current parser token '{'
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  Tue May 10 02:50:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 02:50:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9885] New: Regression: clang crashes when compiling
 current libc++ while parsing <locale>'s time_put
Message-ID: <bug-9885-206@http.llvm.org/bugs/>

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

           Summary: Regression: clang crashes when compiling current
                    libc++ while parsing <locale>'s time_put
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Trying to build the current libc++ results in a clang crash. It crashes while
parsing the <locale> header.

The same happens with the following reduced test case:

class string;
class ios_base;
struct _xlocale;
struct tm;
typedef struct _xlocale * locale_t;
typedef unsigned long size_t;

class __time_put
{
    locale_t __loc_;
protected:
    __time_put(const string& __nm);
};

template <class _CharT, class _OutputIterator>
class __attribute__ ((__visibility__("default"))) time_put
    : private __time_put
{
protected:
    // Commenting this constructor removes the crash:
    __attribute__ ((__visibility__("hidden"), __always_inline__))
    explicit time_put(const string& __nm, size_t __refs)
        // Commenting the base class constructor call removes the crash:
        : __time_put(__nm) {}
};

int main(int, char**)
{
}


This results in:

getSpecialMember on non-special member
UNREACHABLE executed at
/Users/rynnsauer/LLVM/llvm/tools/clang/lib/Sema/SemaDecl.cpp:1521!
[...]
Stack dump:
0.    Program arguments: /opt/bin/clang -cc1 -triple x86_64-apple-macosx10.6.7
-emit-obj -mrelax-all -disable-free -main-file-name clang.cpp -pic-level 1
-mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 97.17 -resource-dir /opt/bin/../lib/clang/3.0
-nostdinc++ -cxx-isystem /usr/include/c++/v1 -std=c++0x -fdeprecated-macro
-ferror-limit 19 -fmessage-length 100 -stack-protector 1 -fblocks
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/RI/RI4iqAygH0OWeTzP0+rLU++++TI/-Tmp-/cc-v4anXa.o -x c++ clang.cpp 
1.    clang.cpp:24:22: current parser token '{'
2.    clang.cpp:16:1: parsing struct/union/class body 'time_put'


My clang version:

$ /opt/bin/clang --version
clang version 3.0 (trunk 131121)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

This did not happen with clang trunk 131082.

Complete crash log to follow.

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

From bugzilla-daemon at llvm.org  Tue May 10 06:08:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 06:08:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8495] [IRGen] Assertion "Instruction does not
 dominate all uses!"
In-Reply-To: <bug-8495-206@http.llvm.org/bugs/>
References: <bug-8495-206@http.llvm.org/bugs/>
Message-ID: <20110510110828.E29DF2A6C124@llvm.org>

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

Elias Pipping <pipping at exherbo.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #6 from Elias Pipping <pipping at exherbo.org> 2011-05-10 06:08:28 CDT ---
I can no longer reproduce this either.

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

From bugzilla-daemon at llvm.org  Tue May 10 06:27:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 06:27:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9726] -O2 -ftree-vectorize
 -fplugin-arg-dragonegg-enable-gcc-optzns fails to compile output_vtk.c
In-Reply-To: <bug-9726-206@http.llvm.org/bugs/>
References: <bug-9726-206@http.llvm.org/bugs/>
Message-ID: <20110510112740.537592A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-05-10 06:27:39 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110509/120591.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 May 10 08:52:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 08:52:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9724] -O2 -fplugin-arg-dragonegg-enable-gcc-optzns
 -ftree-vectorize fails to compile lr_states_plm.c
In-Reply-To: <bug-9724-206@http.llvm.org/bugs/>
References: <bug-9724-206@http.llvm.org/bugs/>
Message-ID: <20110510135210.EFCBF2A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-05-10 08:52:10 CDT ---
After this patch

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110509/120596.html
the testcase fails in the same way as PR9714.

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

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

From bugzilla-daemon at llvm.org  Tue May 10 09:02:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 09:02:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9885] Regression: clang crashes when compiling
 constructor call to protected base constructor with argument
In-Reply-To: <bug-9885-206@http.llvm.org/bugs/>
References: <bug-9885-206@http.llvm.org/bugs/>
Message-ID: <20110510140226.DC00B2A6C12E@llvm.org>

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

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 #5 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-05-10 09:02:26 CDT ---


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

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

From bugzilla-daemon at llvm.org  Tue May 10 09:14:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 09:14:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9884] Assert when derived class calls base class
 constructor with protected visibility
In-Reply-To: <bug-9884-206@http.llvm.org/bugs/>
References: <bug-9884-206@http.llvm.org/bugs/>
Message-ID: <20110510141416.E09C62A6C12C@llvm.org>

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

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

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

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

From bugzilla-daemon at llvm.org  Tue May 10 09:54:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 09:54:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9886] New: cmake build enables exceptions in more
 files than configure
Message-ID: <bug-9886-206@http.llvm.org/bugs/>

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

           Summary: cmake build enables exceptions in more files than
                    configure
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es


For example:

$ readelf -SW
../build/lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/LLVMTargetMachine.cpp.o | grep
gcc

  [77] .gcc_except_table PROGBITS        0000000000000000 002890 0004f0 00   A 
0   0  4

$ readelf -SW lib/CodeGen/Debug+Asserts/LLVMTargetMachine.o | grep gcc
$

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

From bugzilla-daemon at llvm.org  Tue May 10 10:53:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 10:53:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9887] New: "unable to pass LLVM bit-code files to
 linker" when compiling with -O4
Message-ID: <bug-9887-206@http.llvm.org/bugs/>

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

           Summary: "unable to pass LLVM bit-code files to linker" when
                    compiling with -O4
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bartosz.szurgot at pwr.wroc.pl
                CC: llvmbugs at cs.uiuc.edu


$ clang bug.c -O3 && echo OK
OK
$ clang bug.c -O4 && echo OK
clang: error: 'x86_64-pc-linux-gnu': unable to pass LLVM bit-code files to
linker

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

From bugzilla-daemon at llvm.org  Tue May 10 12:21:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 12:21:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9888] New: Crash when parsing a piece of template
 metaprogramming code.
Message-ID: <bug-9888-206@http.llvm.org/bugs/>

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

           Summary: Crash when parsing a piece of template metaprogramming
                    code.
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicola.gigante at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The attached source file reproduce a "Segmentation fault" error in the latest
svn clang,
revision 131131.

I've only access to OS X machines but it doesn't seem to be related to
hardware/OS issues.

I can reproduce the bug with the following command:
clang -cc1 -fsyntax-only test.cpp

gdb says:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3ffff8
0x00000001006a91c6 in clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformTemplateArgument ()

The full backtrace is attached with the source file.

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

From bugzilla-daemon at llvm.org  Tue May 10 12:38:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 12:38:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9883] Assertion `valid() && "Cannot access invalid
 iterator"' failed.
In-Reply-To: <bug-9883-206@http.llvm.org/bugs/>
References: <bug-9883-206@http.llvm.org/bugs/>
Message-ID: <20110510173804.BDEB62A6C124@llvm.org>

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

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

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

--- Comment #1 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-10 12:38:04 CDT ---
Fixed in r131133

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

From bugzilla-daemon at llvm.org  Tue May 10 12:54:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 12:54:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9889] New: Assertion failed:
 (*(block->succ_begin()+1) == dstBlock), function getValueVector,
 file UninitializedValues.cpp, line 231.
Message-ID: <bug-9889-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (*(block->succ_begin()+1) ==
                    dstBlock), function getValueVector, file
                    UninitializedValues.cpp, line 231.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


this occurs only with -Wall

pes delta$ clang -Wall parser.c
parser.c:16:7: warning: control reaches end of non-void function
[-Wreturn-type]
      }
      ^
parser.c:20:17: warning: switch condition has boolean value
  ...switch ((((*x).buffer[i0]).type == ((enum cpp_ttype) (((enum cpp_ttype)
(N_TTYPES + 1)) + 1))) || (((*x).buffer[i0]).type == ((enum cpp_ttype) (((enum
cpp_ttype) (((enum cpp_ttype) (N_TTYPES + 1)) + 1)) + 1)))...
     ^      
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Assertion failed: (*(block->succ_begin()+1) == dstBlock), function
getValueVector, file UninitializedValues.cpp, line 231.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.1 -emit-obj -mrelax-all -disable-free -main-file-name
parser.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.15 -momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/3.0
-Wall -ferror-limit 19 -fmessage-length 152 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-tdgPgg.o -x c parser.c 
1.      <eof> parser at end of file
2.      parser.c:17:46: parsing function body 'gt_ggc_mx_cp_lexer'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Tue May 10 12:58:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 12:58:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9890] New: Should accept -ftemplate-depth=N with a
	warning
Message-ID: <bug-9890-206@http.llvm.org/bugs/>

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

           Summary: Should accept -ftemplate-depth=N with a warning
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu


For some silly reason, GCC used

  -ftemplate-depth-N

rather than the more obvious

  -ftemplate-depth=N

and we mimic that behavior. At the very least, we should support

  -ftemplate-depth=N

as an alias (and perhaps provide a warning at the driver level).

To see why:

$ cat test.cpp
template<bool b, int t, int f>
struct _if {
  static const int result = f;
};

template<int t, int f>
struct _if<true, t, f> {
  static const int result = t;
};

template<int i>
struct fact {
  static const int result = _if<i == 0, 1, i*fact<i - 1>::result>::result;
};

int main()
{
  int a = fact<4>::result;
}

$ clang++ -ftemplate-depth=100 test.cpp 
clang: error: unable to execute command: Segmentation fault: 11
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 May 10 13:08:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 13:08:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9887] "unable to pass LLVM bit-code files to
 linker" when compiling with -O4
In-Reply-To: <bug-9887-206@http.llvm.org/bugs/>
References: <bug-9887-206@http.llvm.org/bugs/>
Message-ID: <20110510180837.7CFCA2A6C124@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2011-05-10 13:08:37 CDT ---
Fixed in head at r118382.

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

From bugzilla-daemon at llvm.org  Tue May 10 13:31:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 13:31:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5907] Takes typedef to non-member class template
 specialization as a member specialization.
In-Reply-To: <bug-5907-206@http.llvm.org/bugs/>
References: <bug-5907-206@http.llvm.org/bugs/>
Message-ID: <20110510183104.F0C9C2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-05-10 13:31:04 CDT ---
Fixed in Clang r131138.

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

From bugzilla-daemon at llvm.org  Tue May 10 13:31:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 13:31:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8277] Clang doesn't allow specifying function
 specialization with a typedef
In-Reply-To: <bug-8277-206@http.llvm.org/bugs/>
References: <bug-8277-206@http.llvm.org/bugs/>
Message-ID: <20110510183144.C8AEC2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-05-10 13:31:44 CDT ---
Fixed in Clang r131138.

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

From bugzilla-daemon at llvm.org  Tue May 10 13:32:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 13:32:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8708] Clang rejects a number of explicit
	specializations
In-Reply-To: <bug-8708-206@http.llvm.org/bugs/>
References: <bug-8708-206@http.llvm.org/bugs/>
Message-ID: <20110510183202.F01942A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-10 13:32:02 CDT ---
Fixed in Clang r131138.

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

From bugzilla-daemon at llvm.org  Tue May 10 13:32:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 13:32:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9482] Use of typedef for class template
 specialization in explicit member specialization across namespaces fails
In-Reply-To: <bug-9482-206@http.llvm.org/bugs/>
References: <bug-9482-206@http.llvm.org/bugs/>
Message-ID: <20110510183227.93F2A2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-05-10 13:32:27 CDT ---
Fixed in Clang r131138.

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

From bugzilla-daemon at llvm.org  Tue May 10 13:32:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 13:32:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9668] parse error when using a typedef for a static
 member variable of a template
In-Reply-To: <bug-9668-206@http.llvm.org/bugs/>
References: <bug-9668-206@http.llvm.org/bugs/>
Message-ID: <20110510183241.DF2342A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-10 13:32:41 CDT ---
Fixed in Clang r131138.

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

From bugzilla-daemon at llvm.org  Tue May 10 13:32:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 13:32:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9877] cannot define member of explicitly
 specialized member class
In-Reply-To: <bug-9877-206@http.llvm.org/bugs/>
References: <bug-9877-206@http.llvm.org/bugs/>
Message-ID: <20110510183255.9FA592A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-10 13:32:55 CDT ---
Fixed in Clang r131138.

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

From bugzilla-daemon at llvm.org  Tue May 10 15:07:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 15:07:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9891] New: static const struct optimized-away
 incorrectly by llvm-gcc
Message-ID: <bug-9891-206@http.llvm.org/bugs/>

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

           Summary: static const struct optimized-away incorrectly by
                    llvm-gcc
           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: stash at cpan.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6573)
 --> (http://llvm.org/bugs/attachment.cgi?id=6573)
Program that fails to run correctly after compiling with llvm-gcc

An anonymous struct defined as "static const" seems to be optimized-away when
llvm-gcc is given the '-O' flag. I'd expect the attached program to print
something, but it does not.  

The following things seem to restore correct behaviour:
* change "static const" to just "const" (i.e. don't use a static initializer)
* use gcc instead of llvm-gcc
* compile *without* the -O flag (or use -O0)

I saw that clang doesn't currently support static initialization of flexible
members, but the struct in this program isn't a member of anything.

I'm not sure that this is an llvm bug since I'm using Apple's llvm-gcc included
in Xcode 4.0.2.  --version: 

i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658)
(LLVM build 2335.9)

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

From bugzilla-daemon at llvm.org  Tue May 10 15:14:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 15:14:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9892] New: clang can miscompile GNU gettext's
	xgettext.c
Message-ID: <bug-9892-206@http.llvm.org/bugs/>

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

           Summary: clang can miscompile GNU gettext's xgettext.c
           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: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6574)
 --> (http://llvm.org/bugs/attachment.cgi?id=6574)
Excerpt from xgettext.c, demonstrating miscompilation

After building GNU gettext 0.18.1.1 on FreeBSD, using clang r131133, I
noted that any invocation of the 'xgettext' tool, whether with or
without arguments, resulted in an error:

xgettext: A --flag argument doesn't have the <keyword>:<argnum>:[pass-]<flag>
syntax: gettext:1:pass-c-format

Compiling the same program without optimization, or using gcc, gives the
expected behaviour.

I reduced the code that is miscompiled to the attached sample.  If you
compile this using clang -O0, and run it, it prints "good", followed by
the two pointer values that have just been checked for equality.

If you compile it using clang -O1, or clang -O2, it prints "bad",
followed by the two pointer values again.

Strangely, at -O3, the failure 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  Tue May 10 17:12:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 17:12:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9889] Assertion failed: (*(block->succ_begin()+1)
 == dstBlock), function getValueVector, file UninitializedValues.cpp,
 line 231.
In-Reply-To: <bug-9889-206@http.llvm.org/bugs/>
References: <bug-9889-206@http.llvm.org/bugs/>
Message-ID: <20110510221204.34E612A6C124@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2011-05-10 17:12:03 CDT ---
fixed:

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

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

From bugzilla-daemon at llvm.org  Tue May 10 18:10:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 18:10:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9893] New: "Invalid GetElementPtrInst indices for
 type!" on valid structure
Message-ID: <bug-9893-206@http.llvm.org/bugs/>

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

           Summary: "Invalid GetElementPtrInst indices for type!" on valid
                    structure
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alonzakai at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code fails to compile with clang:

======
#include "stdio.h"

struct usvec
{
  int x;
};

struct shaftbb
{
  union
  {
    int v[2];
    struct { usvec min, max; };
  };

  shaftbb() {}
};

int main()
{
    shaftbb s;
    return 1;
}
======

The error is 

======
clang: /home/alon/Dev/llvm-svn/include/llvm/Instructions.h:278: const
llvm::Type* llvm::checkType(const llvm::Type*): Assertion `Ty && "Invalid
GetElementPtrInst indices for type!"' failed.
0  clang 0x095746a8
Stack dump:
0.    Program arguments:
/home/alon/Dev/llvm-svn/build/Release+Asserts/bin/clang -cc1 -triple
i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name llvm1.cpp
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -target-linker-version 2.20.1 -momit-leaf-frame-pointer
-resource-dir
/home/alon/Dev/llvm-svn/build/Release+Asserts/bin/../lib/clang/3.0
-ferror-limit 19 -fmessage-length 141 -fcxx-exceptions -fexceptions
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ImS38f.o
-x c++ llvm1.cpp 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    llvm1.cpp:16:3: Generating code for declaration 'shaftbb::shaftbb'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)
======

The file compiles ok with gcc.

This is a reduced testcase from pvs.cpp from Sauerbraten (open source FPS)
which I am trying to compile with clang.

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

From bugzilla-daemon at llvm.org  Tue May 10 18:50:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 18:50:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9894] New: "error: use of undeclared identifier" on
 valid template code
Message-ID: <bug-9894-206@http.llvm.org/bugs/>

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

           Summary: "error: use of undeclared identifier" on valid
                    template code
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alonzakai at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


template<class MDL> struct modelcommands
{
  template<class F> void modelcommand(F *fun) {}
  static void setdir(char *name) {}
  modelcommands() { modelcommand(setdir); }
};

template<class MDL> struct vertcommands : modelcommands<MDL>
{
  static void loadpart(char *model) {}
  vertcommands() { modelcommand(loadpart); }
};

int main()
{
  return 1;
}
===

The above code compiles ok in gcc but fails in clang, with 

llvm1.cpp:11:20: error: use of undeclared identifier 'modelcommand'
  vertcommands() { modelcommand(loadpart); }
                   ^
1 error generated.

(The code is a reduced case from Sauerbraten, an open source FPS I am trying to
compile with clang.)

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

From bugzilla-daemon at llvm.org  Tue May 10 18:51:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 18:51:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9894] "error: use of undeclared identifier" on
 valid template code
In-Reply-To: <bug-9894-206@http.llvm.org/bugs/>
References: <bug-9894-206@http.llvm.org/bugs/>
Message-ID: <20110510235144.CBD112A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-10 18:51:44 CDT ---
Clang is correct; GCC is wrong to accept this code. Please see

  http://clang.llvm.org/compatibility.html#dep_lookup_bases

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

From bugzilla-daemon at llvm.org  Tue May 10 20:06:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 20:06:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9895] New: missed optz'n on uadd.with.overflow
Message-ID: <bug-9895-206@http.llvm.org/bugs/>

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

           Summary: missed optz'n on uadd.with.overflow
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


This is a missed optimization I found doing a superoptimizer run, and it occurs
plenty often in our code:

; Input: 00:07:07:12:-0001:01:-0005:-0005:2b:35:0e:05:-0009:-0004:37:35:2b
declare {i8, i1} @llvm.uadd.with.overflow.i8(i8, i8)
define i1 @test(i8 %X, i8 %Y) {
  %x = sub i8 %X, %Y
  %A = icmp eq i8 %X, %Y
  %y = select i1 %A, i8 1, i8 %x

  %B = call {i8, i1} @llvm.uadd.with.overflow.i8(i8 %y, i8 %x)
  %C = extractvalue {i8, i1} %B, 0
  %D = extractvalue {i8, i1} %B, 1
  %E = select i1 %D, i8 -1, i8 %C
  %F = icmp eq i8 %E, 0
  ret i1 %F
}

It always returns false, but the optimizer doesn't understand the correlation
between %y and %C. If it did, then we would get stuck on this second missed
optzn:

define i1 @test(i8 %X, i8 %Y) nounwind readnone {
  %x = sub i8 %X, %Y
  %A = icmp eq i8 %X, %Y  ; implies %x = 0
  %y = select i1 %A, i8 1, i8 %x  ; actually select i1 %A, i8 1, i8 0
  %ZZZ = sub i8 0, %x
  %F1 = icmp eq i8 %y, %ZZZ
  ret i1 %F1
}

If we do that substitution manually, we get down to this:

define i1 @test(i8 %X, i8 %Y) nounwind readnone {
  %A = icmp eq i8 %X, %Y
  %y = zext i1 %A to i8
  %x1 = sub i8 %Y, %X
  %F1 = icmp eq i8 %y, %x1
  ret i1 %F1
}

which is a correlated expr 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  Tue May 10 22:50:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 10 May 2011 22:50:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9896] New: 131172 miscompiles CGVTables.cpp
Message-ID: <bug-9896-206@http.llvm.org/bugs/>

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

           Summary: 131172 miscompiles CGVTables.cpp
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6576)
 --> (http://llvm.org/bugs/attachment.cgi?id=6576)
CGVTables.ll.bz2

Just run with the old and new llc. The differences are small, so hopefully it
will be easy to stop the bad 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  Wed May 11 00:23:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 00:23:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9882] noexcept sometimes returns unexpected value
In-Reply-To: <bug-9882-206@http.llvm.org/bugs/>
References: <bug-9882-206@http.llvm.org/bugs/>
Message-ID: <20110511052305.781672A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-11 00:23:05 CDT ---
r131177.

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

From bugzilla-daemon at llvm.org  Wed May 11 02:06:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 02:06:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9891] static const struct optimized-away
 incorrectly by llvm-gcc
In-Reply-To: <bug-9891-206@http.llvm.org/bugs/>
References: <bug-9891-206@http.llvm.org/bugs/>
Message-ID: <20110511070630.2E6D22A6C12C@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2011-05-11 02:06:29 CDT ---
Works in dragonegg; llvm-gcc is deprecated.

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

From bugzilla-daemon at llvm.org  Wed May 11 03:05:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 03:05:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9897] New: "File format not recognized" when
	compiling with -O4
Message-ID: <bug-9897-206@http.llvm.org/bugs/>

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

           Summary: "File format not recognized" when compiling with -O4
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bartosz.szurgot at pwr.wroc.pl
                CC: llvmbugs at cs.uiuc.edu


$ /opt/clang_trunk/bin/clang -O3 bug.c # OK

$ /opt/clang_trunk/bin/clang -O4 bug.c
/tmp/cc-88IrUz.o: file not recognized: File format not recognized
clang: error: linker command failed with exit code 1 (use -v to see invocation)

$ /opt/clang_trunk/bin/clang -O4 -v bug.c
clang version 3.0 (trunk 131177)
Target: x86_64-unknown-linux-gnu
Thread model: posix
 "/opt/clang_trunk/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu
-emit-llvm-bc -disable-free -main-file-name bug.c -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21.0.20110327
-momit-leaf-frame-pointer -v -resource-dir
/opt/clang_trunk/bin/../lib/clang/3.0 -O3 -ferror-limit 19 -fmessage-length 147
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ApukqU.o
-x c bug.c
clang -cc1 version 3.0 based upon llvm 3.0svn hosted on
x86_64-unknown-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /opt/clang_trunk/bin/../lib/clang/3.0/include
 /usr/include
End of search list.
 "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o a.out
/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.5.2/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.5.2
-L/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../..
/tmp/cc-ApukqU.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.5.2/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.5.2/../../../../lib64/crtn.o
/tmp/cc-ApukqU.o: file not recognized: File format not recognized
clang: error: linker command failed with exit code 1 (use -v to see invocation)

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

From bugzilla-daemon at llvm.org  Wed May 11 04:12:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 04:12:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9897] "File format not recognized" when compiling
	with -O4
In-Reply-To: <bug-9897-206@http.llvm.org/bugs/>
References: <bug-9897-206@http.llvm.org/bugs/>
Message-ID: <20110511091218.EDD182A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-05-11 04:12:18 CDT ---
This is a feature not a bug :)  At -O4 clang outputs LLVM bitcode rather than
object code.  If your system linker does not know how to handle LLVM bitcode
then linking will fail, as you saw.  See http://llvm.org/docs/GoldPlugin.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 May 11 07:06:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 07:06:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9714] -O3 -fplugin-arg-dragonegg-enable-gcc-optzns
 fails to compile rnflow.f90
In-Reply-To: <bug-9714-206@http.llvm.org/bugs/>
References: <bug-9714-206@http.llvm.org/bugs/>
Message-ID: <20110511120607.38B302A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #6 from Duncan Sands <baldrick at free.fr> 2011-05-11 07:06:06 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110509/120643.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 May 11 07:18:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 07:18:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9898] New: debug assertion (and possibly more
 errors) in ~ScopedNullTerminator()
Message-ID: <bug-9898-206@http.llvm.org/bugs/>

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

           Summary: debug assertion (and possibly more errors) in
                    ~ScopedNullTerminator()
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm.org at schrieb.de
                CC: llvmbugs at cs.uiuc.edu


When I start "opt -analyze -view-cfg SomeFile.s" with a Debug-compiled "opt" I
get 

Assertion failed: !str.empty() && str[str.size() - 1] == 0 && "Null char not
present!", file z:\code\llvm\llvm-2.9\lib\support\Windows/Path.inc, line 76

Probably this is because of line 115:

path.erase(--len);

which does not only erase the trailing slash, but also the trailing zero, that
~ScopedNullTerminator() wants to remove later.


Replacing this by

path.erase(--len,1);

seems to fix this.


Cheers,
Jonas

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

From bugzilla-daemon at llvm.org  Wed May 11 08:58:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 08:58:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9886] cmake build enables exceptions in more files
 than configure
In-Reply-To: <bug-9886-206@http.llvm.org/bugs/>
References: <bug-9886-206@http.llvm.org/bugs/>
Message-ID: <20110511135840.A30D32A6C124@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

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

--- Comment #4 from ?scar Fuentes <ofv at wanadoo.es> 2011-05-11 08:58:40 CDT ---
Fixed in r131182 (clang) and r131181 (LLVM).

You are using clang++ but the scripts added the switches only when g++ was
detected.

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

From bugzilla-daemon at llvm.org  Wed May 11 10:14:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 10:14:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9899] New: noexcept for destructors of scalars
Message-ID: <bug-9899-206@http.llvm.org/bugs/>

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

           Summary: noexcept for destructors of scalars
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


It would be wonderful if the following:

#include <iostream>

template <class T> T&& declval() noexcept;

int main()
{
    typedef int T;
    std::cout << noexcept(declval<T>().~T()) << '\n';
}

Output:

1

I would like to use this to build std::is_nothrow_destructible<T>.  At first
glance it seems to be working for everything but scalars.

Apple clang version 3.0 (trunk 131179) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

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

From bugzilla-daemon at llvm.org  Wed May 11 10:50:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 10:50:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9900] New: scalarrepl-ssa can produce invalid code
 for zero sized array members
Message-ID: <bug-9900-206@http.llvm.org/bugs/>

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

           Summary: scalarrepl-ssa can produce invalid code for zero sized
                    array members
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Running opt -scalarrepl-ssa on

-----------------------------
arget datalayout = "e-p:32:32-f64:32:64-i64:32:64-f80:32:32-n8:16:32"
%foobar = type { i32, [0 x i8] }

define void @f(%foobar %arg) {
  %tmp = alloca %foobar
  store %foobar %arg, %foobar* %tmp
  %tmp113 = bitcast %foobar* %tmp to i8*
  ret void
}
---------------------------

Will produce

-------------------------------
target datalayout = "e-p:32:32-f64:32:64-i64:32:64-f80:32:32-n8:16:32"

%foobar = type { i32, [0 x i8] }

define void @f(%foobar %arg) {
  %arg1 = extractvalue %foobar %arg, 0
  %arg2 = extractvalue %foobar %arg, 1
  ret void
}
----------------------------------

llc is happy with the first code, but crashes on the second on
SelectionDAGBuilder::visitExtractValue when it tries to access the first
element of a zero sized ValValueVTs.

We have two options. One is declaring zero sized array values illegal and
fixing scalarrepl to not produce them and the verifier to check for them.
Another one is making CodeGen handle them correctly.

I am don't see much value is having zero size array values, so I am reporting
this on scalarrrepl. Let me know if you think we should allow them and fix
CodeGen instead.

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

From bugzilla-daemon at llvm.org  Wed May 11 12:30:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 12:30:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9901] New: -std=gnu99 produces a warning when
	linking
Message-ID: <bug-9901-206@http.llvm.org/bugs/>

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

           Summary: -std=gnu99 produces a warning when linking
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chantry.xavier at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ clang -std=gnu99 test.c -c
-> no warning
$ clang -std=gnu99 test.o
clang: warning: argument unused during compilation: '-std=gnu99'

When using Makefiles, how can we specify CFLAGS='-std=gnu99' only for building
and not for the linking step ?

It's rather annoying to have lots of useless warning and not any way to even
work around it.

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

From bugzilla-daemon at llvm.org  Wed May 11 15:23:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 15:23:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9902] New: ICE with alias templates
Message-ID: <bug-9902-206@http.llvm.org/bugs/>

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

           Summary: ICE with alias templates
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Apple clang version 3.0 (trunk 131179) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

template <class _Tp, class _Up, bool = false>
struct __allocator_traits_rebind
{
};

template <template <class, class...> class _Alloc, class _Tp, class ..._Args,
class _Up>
struct __allocator_traits_rebind<_Alloc<_Tp, _Args...>, _Up, false>
{
   typedef _Alloc<_Up, _Args...> type;
};

template <class Alloc>
struct allocator_traits
{
   template <class T> using rebind_alloc = typename
__allocator_traits_rebind<Alloc, T>::type;
   template <class T> using rebind_traits = allocator_traits<rebind_alloc<T>>;
};

template <class T>
struct allocator {};

int main()
{
   allocator_traits<allocator<char>>::rebind_alloc<int> a;
}

0  clang             0x0000000100cad682 PrintStackTrace(void*) + 34
1  clang             0x0000000100cadb39 SignalHandler(int) + 601
2  libSystem.B.dylib 0x00007fff81e0e66a _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2115967408
4  clang             0x00000001003c6c97
clang::TemplateDeclInstantiator::VisitTemplateTypeParmDecl(clang::TemplateTypeParmDecl*)
+ 215
5  clang             0x00000001003c9dc3
clang::DeclVisitor<clang::TemplateDeclInstantiator,
clang::Decl*>::Visit(clang::Decl*) + 339
6  clang             0x00000001003c0d54
clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*,
clang::MultiLevelTemplateArgumentList const&) + 372
7  clang             0x00000001003bbf07 (anonymous
namespace)::TemplateInstantiator::TransformDecl(clang::SourceLocation,
clang::Decl*) + 375
8  clang             0x00000001003abe9f clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc) + 5871
9  clang             0x00000001003aa4b9 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) + 233
10 clang             0x00000001003bafab clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc
const&, clang::TemplateArgumentLoc&) + 155
11 clang             0x00000001003bcf91 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&,
clang::TemplateSpecializationTypeLoc, clang::TemplateName) + 2769
12 clang             0x00000001003b89f5 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformNestedNameSpecifierLoc(clang::NestedNameSpecifierLoc,
clang::QualType, clang::NamedDecl*) + 645
13 clang             0x00000001003ac1ba clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc) + 6666
14 clang             0x00000001003aa4b9 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) + 233
15 clang             0x00000001003acb2f clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::QualType) + 79
16 clang             0x00000001003acad6 clang::Sema::SubstType(clang::QualType,
clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation,
clang::DeclarationName) + 54
17 clang             0x00000001003640bd
clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation,
clang::TemplateArgumentListInfo&) + 557
18 clang             0x0000000100365569
clang::Sema::ActOnTemplateIdType(clang::CXXScopeSpec&,
clang::OpaquePtr<clang::TemplateName>, clang::SourceLocation,
clang::SourceLocation, clang::ASTTemplateArgsPtr, clang::SourceLocation) + 729
19 clang             0x00000001001f9df1
clang::Parser::AnnotateTemplateIdTokenAsType() + 65
20 clang             0x000000010020101d
clang::Parser::TryAnnotateTypeOrScopeToken(bool) + 1677
21 clang             0x00000001001fa98b
clang::Parser::isCXXDeclarationSpecifier() + 91
22 clang             0x00000001001fb726
clang::Parser::isCXXTypeId(clang::Parser::TentativeCXXTypeIdContext, bool&) +
38
23 clang             0x00000001001f9e88 clang::Parser::ParseTemplateArgument()
+ 40
24 clang             0x00000001001f990c
clang::Parser::ParseTemplateArgumentList(llvm::SmallVector<clang::ParsedTemplateArgument,
16u>&) + 204
25 clang             0x00000001001f9536
clang::Parser::ParseTemplateIdAfterTemplateName(clang::OpaquePtr<clang::TemplateName>,
clang::SourceLocation, clang::CXXScopeSpec const&, bool,
clang::SourceLocation&, llvm::SmallVector<clang::ParsedTemplateArgument, 16u>&,
clang::SourceLocation&) + 134
26 clang             0x00000001001f9a75
clang::Parser::AnnotateTemplateIdToken(clang::OpaquePtr<clang::TemplateName>,
clang::TemplateNameKind, clang::CXXScopeSpec&, clang::UnqualifiedId&,
clang::SourceLocation, bool) + 133
27 clang             0x00000001001e1644
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr<clang::QualType>, bool, bool*, bool) + 3236
28 clang             0x0000000100201167
clang::Parser::TryAnnotateCXXScopeToken(bool) + 71
29 clang             0x00000001001caf8a
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 4890
30 clang             0x00000001001c6ee6
clang::Parser::ParseSpecifierQualifierList(clang::DeclSpec&) + 70
31 clang             0x00000001001c6bec
clang::Parser::ParseTypeName(clang::SourceRange*,
clang::Declarator::TheContext) + 236
32 clang             0x00000001001d4b2f
clang::Parser::ParseUsingDeclaration(unsigned int,
clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation,
clang::SourceLocation&, clang::AccessSpecifier) + 1343
33 clang             0x00000001001d8474
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 1636
34 clang             0x00000001001f77f2
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier) + 66
35 clang             0x00000001001f7610
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 720
36 clang             0x00000001001f72ab
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 299
37 clang             0x00000001001d8343
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 1331
38 clang             0x00000001001d72c3
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 1475
39 clang             0x00000001001d6925
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 4501
40 clang             0x00000001001ca524
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 2228
41 clang             0x00000001001f7a0c
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier) + 604
42 clang             0x00000001001f7610
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 720
43 clang             0x00000001001f72ab
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 299
44 clang             0x00000001001c9706
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 390
45 clang             0x00000001001fec42
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1394
46 clang             0x00000001001fe6a5
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 229
47 clang             0x00000001001c523d clang::ParseAST(clang::Sema&, bool) +
301
48 clang             0x00000001001a918f clang::CodeGenAction::ExecuteAction() +
671
49 clang             0x00000001000294db
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 875
50 clang             0x0000000100009838
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2536
51 clang             0x00000001000027a5 cc1_main(char const**, char const**,
char const*, void*) + 5221
52 clang             0x00000001000060bb main + 667
53 clang             0x0000000100001334 start + 52
Stack dump:
0.    Program arguments:
/Users/hhinnant/Downloads/current-clang/Developer/usr/bin/clang -cc1 -triple
x86_64-apple-macosx10.6.7 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name test.cpp -pic-level 1 -mdisable-fp-elim
-relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 123.2 -resource-dir
/Users/hhinnant/Downloads/current-clang/Developer/usr/bin/../lib/clang/3.0
-nostdinc++ -cxx-isystem /usr/include/c++/v1 -std=c++0x -fdeprecated-macro
-ferror-limit 19 -fmessage-length 138 -stack-protector 1 -fblocks
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/9S/9SAm-D9iHUW4BIKyeX7pTE+++TI/-Tmp-/cc-msStZM.o -x c++ test.cpp 
1.    test.cpp:16:63: at annotation token 
2.    test.cpp:13:1: parsing struct/union/class body 'allocator_traits'
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  Wed May 11 16:41:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 16:41:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7991] [ms-extensions-undocumented] Flexible array
 members in union
In-Reply-To: <bug-7991-206@http.llvm.org/bugs/>
References: <bug-7991-206@http.llvm.org/bugs/>
Message-ID: <20110511214155.669FA2A6C124@llvm.org>

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

Francois Pichet <pichet2000 at gmail.com> changed:

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

--- Comment #1 from Francois Pichet <pichet2000 at gmail.com> 2011-05-11 16:41:54 CDT ---
This was fixed with r113909.

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

From bugzilla-daemon at llvm.org  Wed May 11 17:24:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 17:24:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3384] Code generator does not support select
 conditions with vector type
In-Reply-To: <bug-3384-206@http.llvm.org/bugs/>
References: <bug-3384-206@http.llvm.org/bugs/>
Message-ID: <20110511222423.B06192A6C124@llvm.org>

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

Henning Thielemann <llvm at henning-thielemann.de> changed:

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

--- Comment #4 from Henning Thielemann <llvm at henning-thielemann.de> 2011-05-11 17:24:23 CDT ---


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

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

From bugzilla-daemon at llvm.org  Wed May 11 19:09:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 19:09:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9902] ICE with alias templates
In-Reply-To: <bug-9902-206@http.llvm.org/bugs/>
References: <bug-9902-206@http.llvm.org/bugs/>
Message-ID: <20110512000929.B2A962A6C12C@llvm.org>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-05-11 19:09:28 CDT ---
Fixed in r131211. Thanks for the simple testcase!

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

From bugzilla-daemon at llvm.org  Wed May 11 21:14:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 21:14:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9899] noexcept for destructors of scalars
In-Reply-To: <bug-9899-206@http.llvm.org/bugs/>
References: <bug-9899-206@http.llvm.org/bugs/>
Message-ID: <20110512021409.650322A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-11 21:14:09 CDT ---
r131220.

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

From bugzilla-daemon at llvm.org  Wed May 11 22:11:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 22:11:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9903] New: Member function typedef on weird
	declaration crash
Message-ID: <bug-9903-206@http.llvm.org/bugs/>

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

           Summary: Member function typedef on weird declaration crash
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: scshunt at csclub.uwaterloo.ca
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following crashes clang:

struct foo {
  typedef void bar() try { }
};

This is because the error recovery for a typedef in
Parser::ParseCXXClassMemberDeclaration (around line 1650 or so of
ParseDeclCXX.cpp) incorrectly assumes it's looking at a left brace and crashes
on ConsumeBrace().

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

From bugzilla-daemon at llvm.org  Wed May 11 22:40:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 22:40:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9904] New: lit doesn't delete %t directories
Message-ID: <bug-9904-206@http.llvm.org/bugs/>

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

           Summary: lit doesn't delete %t directories
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: lit
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org


There's a bunch of tests now that use "rm -rf %t" to clear out directories they
create in between runs. This is something that lit should do, it should clear
out files or directories named %t*.

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

From bugzilla-daemon at llvm.org  Wed May 11 22:43:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 11 May 2011 22:43:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8131] alpha: ICE at gcc/libgcc2.c:567
In-Reply-To: <bug-8131-206@http.llvm.org/bugs/>
References: <bug-8131-206@http.llvm.org/bugs/>
Message-ID: <20110512034354.0A7522A6C124@llvm.org>

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

Matt Turner <mattst88 at gmail.com> changed:

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

--- Comment #8 from Matt Turner <mattst88 at gmail.com> 2011-05-11 22:43:53 CDT ---
llvm-gcc isn't maintained anymore, so forget about this.

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

From bugzilla-daemon at llvm.org  Thu May 12 07:48:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 12 May 2011 07:48:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8899] including fenv.h fails on linux
In-Reply-To: <bug-8899-206@http.llvm.org/bugs/>
References: <bug-8899-206@http.llvm.org/bugs/>
Message-ID: <20110512124832.1C0FF2A6C12E@llvm.org>

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

Michael Wild <themiwi at users.sourceforge.net> changed:

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

--- Comment #5 from Michael Wild <themiwi at users.sourceforge.net> 2011-05-12 07:48:31 CDT ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 12 07:53:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 12 May 2011 07:53:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9905] New: Failure in code selection for llvm
 intrinsics sqrt/exp
Message-ID: <bug-9905-206@http.llvm.org/bugs/>

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

           Summary: Failure in code selection for llvm intrinsics sqrt/exp
           Product: tools
           Version: 2.9
          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


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

Hello,

When trying to llvm intrinsics sqrt/exp with vector datatype for ARM v7a
targets I've got following error:

LLVM ERROR: Cannot select: 0x9315a00: v4f32 = fsqrt 0x9315ca8 [ORD=2] [ID=8]
  0x9315ca8: v4f32 = bit_convert 0x9315c20 [ID=7]
    0x9315c20: v2f64,ch = load 0x9302624, 0x9315b98, 0x93158f0<LD16[@A]> [ID=6]
      0x9315b98: i32 = ARMISD::Wrapper 0x9315868 [ID=5]
        0x9315868: i32 = TargetGlobalAddress<<4 x float>* @A> 0 [ID=3]
      0x93158f0: i32 = undef [ORD=1] [ID=2]

To reproduce the problem use llc 2.9 on attached file as follows:

llc sqrtv4.ll -march=arm -mcpu=cortex-a9

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 12 07:55:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 12 May 2011 07:55:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8610] include search path breaks include_next
In-Reply-To: <bug-8610-206@http.llvm.org/bugs/>
References: <bug-8610-206@http.llvm.org/bugs/>
Message-ID: <20110512125546.3132F2A6C130@llvm.org>

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

Michael Wild <themiwi at users.sourceforge.net> changed:

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

--- Comment #7 from Michael Wild <themiwi at users.sourceforge.net> 2011-05-12 07:55:45 CDT ---
Ugh, sorry for the noise, just noticed that the whole analysis has already been
done in #6907 (somehow I skipped that one initially...)

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

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

From bugzilla-daemon at llvm.org  Thu May 12 11:03:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 12 May 2011 11:03:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9906] New: Clang incorrectly fails to detect nested
 struct in class definition with Boost.
Message-ID: <bug-9906-206@http.llvm.org/bugs/>

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

           Summary: Clang incorrectly fails to detect nested struct in
                    class definition with Boost.
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jon at funkitron.com
                CC: llvmbugs at cs.uiuc.edu


Overview:
  In a program which #includes boost's Trim algorithm, if both the boost and
std namespace are brought into the global namespace with a "using" declaration,
the compiler will improperly fail to detect an internal struct of a class named
"iterator".

Steps to Reproduce (Note: There may be simpler steps to reproduce): 

1. Create a new command line program project in xcode 4.0.2.
2. Change program text to:

#include <boost/algorithm/string/trim.hpp>

using namespace std;
using namespace boost;

class Test {
    struct iterator {

    };

    friend struct Test::iterator;
};

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

3. Install Boost 1.41
4. Add reference to Boost 1.41 to project's header referenes.




Actual Results: 

/Compiler Breaker/Compiler Breaker/Compiler
Breaker/main.cpp:19:25:{19:19-19:25}: error: no struct named 'iterator' in
'Test' [2]

Expected Results: Program should compile normally.

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

Additional Information:

Removing either Using Namespace tag will cause the error to go away.
Renaming the struct from "iterator" to "notiterator" will cause the error to go
away.
Program compiles without objection in LLVM GCC 4.2. A much more complicated
version of the program compiled successfully in visual studios 2005.
There is a struct iterator class added to the boost namespace in
boost/iterator.hpp line 55.
There is a struct iterator class added to the std namespace in
stl_iterator_base_types.h in the mac os 10.6 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  Thu May 12 15:25:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 12 May 2011 15:25:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9907] New: LLVM drops line number information for
 variables that have debug information attached to PHI nodes
Message-ID: <bug-9907-206@http.llvm.org/bugs/>

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

           Summary: LLVM drops line number information for variables that
                    have debug information attached to PHI nodes
           Product: libraries
           Version: 2.7
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6584)
 --> (http://llvm.org/bugs/attachment.cgi?id=6584)
optimized bitcode that loosed debug information

This bug requires the patch from bug9879 to be applied to see the variables
exist in the debug_info section.

This is what is produce with llc --march=x86 <file>:
___OpenCL_nbt01_kernel:
Lfunc_begin0:
    .loc    1 2 0
    pushl    %ebx
Ltmp0:
    pushl    %edi
Ltmp1:
    pushl    %esi
Ltmp2:
Ltmp3:
    calll    ___amdil_get_local_id_int
    movd    %xmm0, %esi
    movl    16(%esp), %edi
    calll    ___amdil_get_global_id_int
    movd    %xmm0, %ebx
    calll    ___amdil_get_local_size_int
    movd    %xmm0, %eax
Ltmp4:
    .loc    1 9 26
    addl    %ebx, %esi
Ltmp5:
    addl    %eax, %esi
    movl    %esi, (%edi)
Ltmp6:
    .loc    1 10 1
    popl    %esi
    popl    %edi
Ltmp7:
    popl    %ebx
Ltmp8:
    ret
Ltmp9:
Lfunc_end0:

This is what is expected:
___OpenCL_nbt01_kernel:
Lfunc_begin0:
    .loc    1 2 0
    pushl    %ebx
Ltmp0:
    pushl    %edi
Ltmp1:
    pushl    %esi
Ltmp2:
Ltmp3:
    calll    ___amdil_get_local_id_int
    movd    %xmm0, %esi
Ltmp4:
        .loc    1 5 26
    movl    16(%esp), %edi
    calll    ___amdil_get_global_id_int
    movd    %xmm0, %ebx
Ltmp5:
        .loc    1 6 27
    calll    ___amdil_get_local_size_int
    movd    %xmm0, %eax
Ltmp6:
        .loc    1 7 28
Ltmp7:
    .loc    1 9 26
    addl    %ebx, %esi
Ltmp8:
    addl    %eax, %esi
    movl    %esi, (%edi)
Ltmp9:
    .loc    1 10 1
    popl    %esi
    popl    %edi
Ltmp10:
    popl    %ebx
Ltmp11:
    ret
Ltmp12:
Lfunc_end0:

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 12 20:43:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 12 May 2011 20:43:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9908] New: alias templates,
	something is not quite right
Message-ID: <bug-9908-206@http.llvm.org/bugs/>

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

           Summary: alias templates, something is not quite right
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Apple clang version 3.0 (trunk 131228) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

template <class _Tp, class _Up>
struct __allocator_traits_rebind
{
    typedef typename _Tp::template rebind<_Up>::other type;
};

template <class Alloc>
struct allocator_traits
{
    typedef Alloc allocator_type;
    template <class T> using rebind_alloc = typename
__allocator_traits_rebind<allocator_type, T>::type;
    template <class T> using rebind_traits = allocator_traits<rebind_alloc<T>>;
};

template <class T>
struct ReboundA {};

template <class T>
struct A
{
    typedef T value_type;

    template <class U> struct rebind {typedef ReboundA<U> other;};
};


int main()
{
    allocator_traits<A<char> >::rebind_traits<double> a;
}


test.cpp:242:33: error: no member named 'rebind_traits' in
'allocator_traits<A<char> >'
    allocator_traits<A<char> >::rebind_traits<double> a;
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
test.cpp:242:53: error: expected '(' for function-style cast or type
construction
    allocator_traits<A<char> >::rebind_traits<double> a;
                                              ~~~~~~^
test.cpp:242:55: error: use of undeclared identifier 'a'
    allocator_traits<A<char> >::rebind_traits<double> a;
                                                      ^
3 errors generated.

Expecting no error.

And the wild thing is the workaround:  Use the template parameter Alloc
directly, instead of the type allocator_type, in the definition of
rebind_alloc, and then rebind_traits behaves 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  Thu May 12 21:47:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 12 May 2011 21:47:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9909] New: EmitGlobalFunctionDefinition ignores
	Annotations
Message-ID: <bug-9909-206@http.llvm.org/bugs/>

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

           Summary: EmitGlobalFunctionDefinition ignores Annotations
           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: mcyril at gmail.com
                CC: llvmbugs at cs.uiuc.edu


There are no corresponded code in CodeGenModule::EmitGlobalFunctionDefinition
to add annotation attributes to Annotations array (though this code is in
CodeGenModule::EmitGlobalVarDefinition). As the result clang ignores functions'
__attribute__((annotate("blah-blah-blah"))) declarations.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 06:39:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 06:39:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9713] -O3 -fplugin-arg-dragonegg-enable-gcc-optzns
 fails to compile protein.f90
In-Reply-To: <bug-9713-206@http.llvm.org/bugs/>
References: <bug-9713-206@http.llvm.org/bugs/>
Message-ID: <20110513113911.A6EED2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2011-05-13 06:39:11 CDT ---
This has probably been fixed.  Closing since I did not get any feedback from
the reporter confirming this.

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

From bugzilla-daemon at llvm.org  Fri May 13 06:40:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 06:40:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9715] -O3 -fplugin-arg-dragonegg-enable-gcc-optzns
 fails to compile test_fpu.f90
In-Reply-To: <bug-9715-206@http.llvm.org/bugs/>
References: <bug-9715-206@http.llvm.org/bugs/>
Message-ID: <20110513114029.6E9C32A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #4 from Duncan Sands <baldrick at free.fr> 2011-05-13 06:40:29 CDT ---
No testcase.

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

From bugzilla-daemon at llvm.org  Fri May 13 10:04:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 10:04:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3352] SplitVectorOperand assert on v4f32 select
In-Reply-To: <bug-3352-206@http.llvm.org/bugs/>
References: <bug-3352-206@http.llvm.org/bugs/>
Message-ID: <20110513150459.194FC2A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #11 from Duncan Sands <baldrick at free.fr> 2011-05-13 10:04:58 CDT ---


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

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

From bugzilla-daemon at llvm.org  Fri May 13 10:05:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 10:05:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9717] -ffast-math -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns fails to compile aermod.f90
In-Reply-To: <bug-9717-206@http.llvm.org/bugs/>
References: <bug-9717-206@http.llvm.org/bugs/>
Message-ID: <20110513150533.05B142A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #6 from Duncan Sands <baldrick at free.fr> 2011-05-13 10:05:32 CDT ---
This is now waiting on PR2314 (codegen support for vector select).

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

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

From bugzilla-daemon at llvm.org  Fri May 13 11:55:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 11:55:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9910] New: Constructor mistakenly marked deleted
Message-ID: <bug-9910-206@http.llvm.org/bugs/>

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

           Summary: Constructor mistakenly marked deleted
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Apple clang version 3.0 (trunk 131287) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

class money_base
{
public:
    enum part {none, space, symbol, sign, value};
    struct pattern {char field[4];};
};

class  moneypunct
    : public money_base
{
public:

protected:

    virtual pattern do_neg_format() const
        {pattern __p = {symbol, sign, none, value}; return __p;}
};

int main()
{
}


test.cpp:17:60: error: call to deleted constructor of 'money_base::pattern'
        {pattern __p = {symbol, sign, none, value}; return __p;}
                                                           ^~~
test.cpp:6:12: note: function has been explicitly marked deleted here
    struct pattern {char field[4];};
           ^
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 May 13 12:16:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 12:16:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9118] Windows platform Endian-ness not defined
In-Reply-To: <bug-9118-206@http.llvm.org/bugs/>
References: <bug-9118-206@http.llvm.org/bugs/>
Message-ID: <20110513171619.B7A132A6C12C@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #2 from Howard Hinnant <hhinnant at apple.com> 2011-05-13 12:16:19 CDT ---
Committed revision 131296.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 12:25:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 12:25:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8930] std::ios_base is not forward declared by
	<iosfwd>
In-Reply-To: <bug-8930-206@http.llvm.org/bugs/>
References: <bug-8930-206@http.llvm.org/bugs/>
Message-ID: <20110513172529.5D37E2A6C12C@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2011-05-13 12:25:29 CDT ---
I apparently fixed this some time ago and forgot to close this.

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

From bugzilla-daemon at llvm.org  Fri May 13 12:26:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 12:26:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9087] mingw-w64: __include/config tries to include
 endian.h, which is not present on Windows
In-Reply-To: <bug-9087-206@http.llvm.org/bugs/>
References: <bug-9087-206@http.llvm.org/bugs/>
Message-ID: <20110513172646.9017E2A6C12C@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2011-05-13 12:26:46 CDT ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 13:14:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 13:14:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8454] Clang writes ObjC string literals as UTF-16
 if they contain UTF-8 characters
In-Reply-To: <bug-8454-206@http.llvm.org/bugs/>
References: <bug-8454-206@http.llvm.org/bugs/>
Message-ID: <20110513181400.CE5D92A6C12D@llvm.org>

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

Fariborz Jahanian <fjahanian at apple.com> changed:

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

--- Comment #9 from Fariborz Jahanian <fjahanian at apple.com> 2011-05-13 13:14:00 CDT ---
Your patch went in in r131298.

(In reply to comment #8)
> Yes, this is indeed intended, as for Cocoa, it emits UTF-16 if there are
> unicode characters in the string and sets a flag to signal that to the class.
> However, there is no such flag when using -fconstant-string-class
> -fno-constant-cfstrings, so it should always just write UTF-8.
> 
> Sorry about the wrong bug report, the correct number is #6056.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 13:44:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 13:44:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9335] Overeager setting of eof()
In-Reply-To: <bug-9335-206@http.llvm.org/bugs/>
References: <bug-9335-206@http.llvm.org/bugs/>
Message-ID: <20110513184425.172CA2A6C12C@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

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

From bugzilla-daemon at llvm.org  Fri May 13 16:17:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 16:17:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8765] backend should generate right name for
	longjmp on netbsd
In-Reply-To: <bug-8765-206@http.llvm.org/bugs/>
References: <bug-8765-206@http.llvm.org/bugs/>
Message-ID: <20110513211720.86B5C2A6C12D@llvm.org>

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

J?rg Sonnenberger <joerg at NetBSD.org> changed:

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

--- Comment #15 from J?rg Sonnenberger <joerg at NetBSD.org> 2011-05-13 16:17:19 CDT ---
Fixed with r131311.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 16:53:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 16:53:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9854] <cmath> undefs symbols from the global
	namespace
In-Reply-To: <bug-9854-206@http.llvm.org/bugs/>
References: <bug-9854-206@http.llvm.org/bugs/>
Message-ID: <20110513215314.760DC2A6C124@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2011-05-13 16:53:13 CDT ---
Committed revision 131318.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 13 16:55:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 16:55:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9911] New: Bad typo correction: variable name
	"fool" -> "bool"
Message-ID: <bug-9911-206@http.llvm.org/bugs/>

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

           Summary: Bad typo correction: variable name "fool" -> "bool"
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthewbg at google.com
                CC: llvmbugs at cs.uiuc.edu, nlewycky at google.com


The following code produces some terrible diagnostics:
int *test(UnknownType *fool) { return 0; }

<stdin>:1:11: error: use of undeclared identifier 'UnknownType'
int *test(UnknownType *fool) { return 0; }
          ^
<stdin>:1:24: error: use of undeclared identifier 'fool'; did you mean 'bool'?
int *test(UnknownType *fool) { return 0; }
                       ^
<stdin>:1:29: error: expected ';' after top level declarator
int *test(UnknownType *fool) { return 0; }
                            ^
                            ;
3 errors generated.

Nick's comment on our internal bug:
Because it didn't know "UnknownType" it tried to autocorrect fool to bool. No
clang, no. And then what's with putting the ; after it, this is a function
definition!

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

From bugzilla-daemon at llvm.org  Fri May 13 19:09:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 13 May 2011 19:09:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9912] New: ScheduleDAGRRList.cpp does not take
 debug information into account
Message-ID: <bug-9912-206@http.llvm.org/bugs/>

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

           Summary: ScheduleDAGRRList.cpp does not take debug information
                    into account
           Product: libraries
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6588)
 --> (http://llvm.org/bugs/attachment.cgi?id=6588)
test case that shows the problem

The function PickNodeToScheduleBottomUp from ScheduleDAGRRList.cpp does not
take DebugLoc information into account when picking what node to schedule next. 
This causes LLVM to produce the following LLVM .debug_line information:
Line Number Statements:
  Extended opcode 2: set Address to 0x3a
  Special opcode 6: advance Address by 0 to 0x3a and Line by 1 to 2
  Set column to 29
  Extended opcode 2: set Address to 0x3d
  Special opcode 8: advance Address by 0 to 0x3d and Line by 3 to 5
  Set column to 23
  Extended opcode 2: set Address to 0x3f
  Special opcode 3: advance Address by 0 to 0x3f and Line by -2 to 3
  Set column to 29
  Extended opcode 2: set Address to 0x43
  Special opcode 7: advance Address by 0 to 0x43 and Line by 2 to 5
  Set column to 1
  Extended opcode 2: set Address to 0x54
  Special opcode 6: advance Address by 0 to 0x54 and Line by 1 to 6
  Extended opcode 2: set Address to 0x88
  Advance PC by 0 to 88
  Extended opcode 1: End of Sequence

The problem is the jump from line 5 to line 3 and then back to line 5.
This is because in the address calculation of this instruction, 
%tmp8 = load i32 addrspace(1)* %arrayidx7, align 4, !dbg !18,
The source gep instruction ends up being transformed into SDNode where the
operands to the add instruction have debug information from different source
lines. So which dbg.value gets emitted first depends entirely on the ordering
of the operands, which is problematic as if the operand with line number 5 gets
emitted first, then a debugger will jump from line 5 to line 3 when the second
operand gets selected and then jump back to line 5 when the result operand get
selected.

The patch I will provide produces the following debug_line information:
 Line Number Statements:
  Set column to 23
  Extended opcode 2: set Address to 0x3a
  Special opcode 7: advance Address by 0 to 0x3a and Line by 2 to 3
  Set column to 29
  Extended opcode 2: set Address to 0x3f
  Special opcode 7: advance Address by 0 to 0x3f and Line by 2 to 5
  Set column to 1
  Extended opcode 2: set Address to 0x52
  Special opcode 6: advance Address by 0 to 0x52 and Line by 1 to 6
  Extended opcode 2: set Address to 0x76
  Advance PC by 0 to 76
  Extended opcode 1: End of Sequence

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 02:57:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 02:57:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9913] New: Refuses out-of-class definition of class
 in partial specialization
Message-ID: <bug-9913-206@http.llvm.org/bugs/>

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

           Summary: Refuses out-of-class definition of class in partial
                    specialization
           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


clang recently started rejecting this code:

template<class,class=int>struct S;
template<class X>struct S<X> {
        template<class T> class F;
};

template<class A>
template<class B>
class S<A>::F{};

with the error message:

g.cc:6:1: error: too few template parameters in template redeclaration
template<class A>
^~~~~~~~~~~~~~~~~
g.cc:1:1: note: previous template declaration is here
template<class,class=int>struct 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  Sat May 14 07:17:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 07:17:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9914] New: Clang crashes in Globals.cpp
Message-ID: <bug-9914-206@http.llvm.org/bugs/>

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

           Summary: Clang crashes in Globals.cpp
           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 failed: (InitVal->getType() == Ty && "Initializer should be the same
type as the GlobalVariable!"), function GlobalVariable, file Globals.cpp, line
97.
0  clang             0x00000001016e9a32
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
818
1  clang             0x00000001016ea9b3
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
4787
2  libSystem.B.dylib 0x00007fff88f0b66a _sigtramp + 26
3  libSystem.B.dylib 0x0000000102983ce0 _sigtramp + 2041022096
4  clang             0x00000001016e9eb2
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
1970
5  clang             0x00000001015db0be
llvm::GVMaterializer::Dematerialize(llvm::GlobalValue*) + 6014
6  clang             0x00000001002616d5 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 47477
7  clang             0x000000010026180f llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateStructGEP(llvm::Value*, unsigned int, llvm::Twine const&) + 47791
8  clang             0x0000000100239f60 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateFCmp(llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, llvm::Twine
const&) + 24400
9  clang             0x000000010022ae02
clang::CodeGen::CGRecordLayout::getNonVirtualBaseLLVMFieldNo(clang::CXXRecordDecl
const*) const + 45906
10 clang             0x000000010022b8dd
clang::CodeGen::CGRecordLayout::getNonVirtualBaseLLVMFieldNo(clang::CXXRecordDecl
const*) const + 48685
11 clang             0x00000001001eee56
clang::CanQual<clang::Type>::getTypePtr() const + 9910
12 clang             0x00000001001eefcc
clang::CanQual<clang::Type>::getTypePtr() const + 10284
13 clang             0x00000001001a627d llvm::cast_retty<clang::CXXMethodDecl,
clang::CXXDestructorDecl const*>::ret_type llvm::cast<clang::CXXMethodDecl,
clang::CXXDestructorDecl const*>(clang::CXXDestructorDecl const* const&) + 4845
14 clang             0x000000010023e44c void
clang::CodeGen::CodeGenFunction::EmitCallArgs<clang::ObjCMethodDecl>(clang::CodeGen::CallArgList&,
clang::ObjCMethodDecl const*, clang::ConstExprIterator,
clang::ConstExprIterator) + 524
15 clang             0x0000000100239c44 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateFCmp(llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, llvm::Twine
const&) + 23604
16 clang             0x000000010022ae02
clang::CodeGen::CGRecordLayout::getNonVirtualBaseLLVMFieldNo(clang::CXXRecordDecl
const*) const + 45906
17 clang             0x000000010022b8dd
clang::CodeGen::CGRecordLayout::getNonVirtualBaseLLVMFieldNo(clang::CXXRecordDecl
const*) const + 48685
18 clang             0x00000001001ecf88
clang::CanQual<clang::Type>::getTypePtr() const + 2024
19 clang             0x00000001002bf6f4
clang::BackendConsumer::InlineAsmDiagHandler(llvm::SMDiagnostic const&, void*,
unsigned int) + 11780
20 clang             0x00000001002981c2 llvm::DenseMap<clang::FieldDecl const*,
unsigned int, llvm::DenseMapInfo<clang::FieldDecl const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 43298
21 clang             0x0000000100294dd8 llvm::DenseMap<clang::FieldDecl const*,
unsigned int, llvm::DenseMapInfo<clang::FieldDecl const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 30008
22 clang             0x00000001002984fb llvm::DenseMap<clang::FieldDecl const*,
unsigned int, llvm::DenseMapInfo<clang::FieldDecl const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 44123
23 clang             0x00000001002988c2 llvm::DenseMap<clang::FieldDecl const*,
unsigned int, llvm::DenseMapInfo<clang::FieldDecl const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 45090
24 clang             0x0000000100294980 llvm::DenseMap<clang::FieldDecl const*,
unsigned int, llvm::DenseMapInfo<clang::FieldDecl const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 28896
25 clang             0x0000000100234ae7 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateFCmp(llvm::CmpInst::Predicate, llvm::Value*, llvm::Value*, llvm::Twine
const&) + 2775
26 clang             0x00000001002cde10 llvm::DenseMap<clang::Expr const*,
llvm::Value*, llvm::DenseMapInfo<clang::Expr const*>,
llvm::DenseMapInfo<llvm::Value*> >::grow(unsigned int) + 45872
27 clang             0x00000001002e074f llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateExtractValue(llvm::Value*, unsigned int, llvm::Twine const&) + 3231
28 clang             0x00000001002bc48b
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 155
29 clang             0x00000001002ed2c2 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateAdd(llvm::Value*, llvm::Value*, llvm::Twine const&, bool, bool) + 674
30 clang             0x00000001002ba99c
llvm::DenseMap<clang::CodeGen::GlobalDecl, long long,
llvm::DenseMapInfo<clang::CodeGen::GlobalDecl>, llvm::DenseMapInfo<long long>
>::grow(unsigned int) + 2188
31 clang             0x00000001000425f1 llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 8945
32 clang             0x000000010000aac5 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&) + 1893
33 clang             0x0000000100001d18
34 clang             0x0000000100009c82 std::vector<std::string,
std::allocator<std::string> >::operator=(std::vector<std::string,
std::allocator<std::string> > const&) + 12962
35 clang             0x0000000100001134
36 clang             0x000000000000003e
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-apple-macosx10.6.7 -emit-obj -disable-free -main-file-name OFString.m
-pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 123.2 -g -coverage-file OFString.lib.o -resource-dir
/usr/local/bin/../lib/clang/3.0 -D PIC -I . -I .. -I exceptions -O2 -Wall
-Wwrite-strings -Wcast-align -Wpointer-arith -Werror -Wno-unused-variable
-Wno-strict-aliasing -std=gnu99 -fconst-strings -fconstant-string-class
OFConstantString -ferror-limit 19 -fmessage-length 80 -stack-protector 1
-fblocks -fobjc-exceptions -fexceptions -fobjc-nonfragile-abi
-fobjc-dispatch-method=mixed -fno-constant-cfstrings -fno-common
-fdiagnostics-show-option -fcolor-diagnostics -o OFString.lib.o -x objective-c
OFString.m 
1.    OFString.m:1082:1: current parser token '-'
2.    OFString.m:1059:1: LLVM IR generation of declaration
'OFString::XMLElementBySerializing'
3.    OFString.m:1060:1: LLVM IR generation of compound statement ('{}')

Don't really get what is causing this.
Source file: https://webkeks.org/hg/objfw/file/b54168b743d1/src/OFString.m

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

From bugzilla-daemon at llvm.org  Sat May 14 08:33:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 08:33:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9915] New: Clang parses parenthesized identifier as
	a bitfield
Message-ID: <bug-9915-206@http.llvm.org/bugs/>

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

           Summary: Clang parses parenthesized identifier as a bitfield
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I think that clang should not accept this according to the spec:

    struct A { int(a) : 1; };

A bitfield has only a plain "identifier_opt" a the start of its
member-declarator.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 09:15:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 09:15:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9916] New: link-time undefined copy constructor
	when defaulting
Message-ID: <bug-9916-206@http.llvm.org/bugs/>

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

           Summary: link-time undefined copy constructor when defaulting
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I know this area is still under active development.  Just hoping to help with
tests.

The defaulted default constructor appears to be working well.  But I get a link
time error for the copy constructor:

Undefined symbols for architecture x86_64:
  "A::A(A const&)", referenced from:
      _main in cc-y6wi0g.o
ld: symbol(s) not found for architecture x86_64

class A
{
public:
    A() = default;
    A(const A&) = default;
};

int main()
{
    A a;
    A a2 = a;
}

Apple clang version 3.0 (trunk 131335) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

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

From bugzilla-daemon at llvm.org  Sat May 14 10:06:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 10:06:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9908] alias templates, something is not quite right
In-Reply-To: <bug-9908-206@http.llvm.org/bugs/>
References: <bug-9908-206@http.llvm.org/bugs/>
Message-ID: <20110514150652.910722A6C12C@llvm.org>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-05-14 10:06:52 CDT ---
The fix for PR9902 was broken, sorry! This should now be OK in r131342.

The failure was caused by us not being able to look up names in the current
instantiation, due to a template argument level confusion.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 10:20:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 10:20:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9917] New: Crash by including libc++ <valarray> in
	c++0x mode
Message-ID: <bug-9917-206@http.llvm.org/bugs/>

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

           Summary: Crash by including libc++ <valarray> in c++0x mode
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6590)
 --> (http://llvm.org/bugs/attachment.cgi?id=6590)
This is a preprocess of libc++ <valarray>

Just noticed this.  preprocess enclosed.

$ clang++  -std=c++0x  valarray_crash.cpp 
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

$ clang++ --version
Apple clang version 3.0 (trunk 131335) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

Sorry, it is a big enclosure, haven't nailed down what in there is causing the
crash.  Compiles normally without -std=c++0x.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 13:38:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 13:38:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9918] New: exception specification for defaulted
 constructor misses default arguments
Message-ID: <bug-9918-206@http.llvm.org/bugs/>

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

           Summary: exception specification for defaulted constructor
                    misses default arguments
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang ToT fails this test:

  struct S {
    S(int a = (throw "eep", 0)) noexcept;
  };
  struct T : S {
    T() = default;
  };
  static_assert(!noexcept(T()), "noexcept(T()) but T() throws");

The implicitly-generated default constructor for T() uses S::S's default
argument, which is not noexcept, but clang doesn't notice that.

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

From bugzilla-daemon at llvm.org  Sat May 14 16:29:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 16:29:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9919] New: error: binding of reference to type 'A'
 to a value of type 'A' drops qualifiers
Message-ID: <bug-9919-206@http.llvm.org/bugs/>

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

           Summary: error: binding of reference to type 'A' to a value of
                    type 'A' drops qualifiers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I believe this is well-formed code.

struct A {};

template <class _R, class ..._Param, class ..._Args>
inline
_R
__invoke(_R (*__f)(_Param...), _Args&& ...__args)
{
    return __f(static_cast<_Args&&>(__args)...);
}

template <class _F, class _BoundArgs>
inline
A
__apply_functor(_F& __f, _BoundArgs __bound_args)
{
    return ::__invoke(__f, __bound_args);
}


A f4(A&& p)
{
    return static_cast<A&&>(p);
}

int main()
{
    ::__apply_functor(f4, A());
}


test.cpp:9:16: error: binding of reference to type 'A' to a value of type 'A'
drops qualifiers
    return __f(static_cast<_Args&&>(__args)...);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test.cpp:17:12: note: in instantiation of function template specialization
'__invoke<A, A &&, A &>' requested here
    return ::__invoke(__f, __bound_args);
           ^
test.cpp:28:5: note: in instantiation of function template specialization
'__apply_functor<A (A &&), A>' requested here
    ::__apply_functor(f4, A());
    ^
1 error generated.


Apple clang version 3.0 (trunk 131335) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

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

From bugzilla-daemon at llvm.org  Sat May 14 18:26:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 18:26:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9181] Missed optimization on empty virtual
	destructors
In-Reply-To: <bug-9181-206@http.llvm.org/bugs/>
References: <bug-9181-206@http.llvm.org/bugs/>
Message-ID: <20110514232626.822EC2A6C12D@llvm.org>

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

Anders Carlsson <andersca at mac.com> changed:

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

--- Comment #4 from Anders Carlsson <andersca at mac.com> 2011-05-14 18:26:25 CDT ---
Committed revision 131368.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 14 19:02:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 14 May 2011 19:02:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5544] don't emit "shift count is negative" warning
 in dead arm of conditionals
In-Reply-To: <bug-5544-206@http.llvm.org/bugs/>
References: <bug-5544-206@http.llvm.org/bugs/>
Message-ID: <20110515000250.D7CF12A6C12E@llvm.org>

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

Dimitry Andric <dimitry at andric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |dimitry at andric.com
         Resolution|FIXED                       |

--- Comment #12 from Dimitry Andric <dimitry at andric.com> 2011-05-14 19:02:50 CDT ---
Reopening, this bug is not completely fixed yet.

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

From bugzilla-daemon at llvm.org  Sun May 15 04:48:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 15 May 2011 04:48:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5845] compiler-rt build fails at powidf2_test
In-Reply-To: <bug-5845-206@http.llvm.org/bugs/>
References: <bug-5845-206@http.llvm.org/bugs/>
Message-ID: <20110515094812.7735D2A6C12C@llvm.org>

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

arrowdodger <6yearold at gmail.com> changed:

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

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

From bugzilla-daemon at llvm.org  Sun May 15 08:10:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 15 May 2011 08:10:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9920] New: Another case of unnecessary "shift count
 is negative" warning
Message-ID: <bug-9920-206@http.llvm.org/bugs/>

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

           Summary: Another case of unnecessary "shift count is negative"
                    warning
           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: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6598)
 --> (http://llvm.org/bugs/attachment.cgi?id=6598)
Trigger unneeded "shift count is negative" warning

[Creating this as a separate PR.]

This warning still appears while compiling the FreeBSD kernel source tree, even
with ToT, as reported to me by Matthew Fleming.  I just tested a further
reduced version of his sample with trunk r131368, and it gives:

pr5544c.c:4:17: warning: shift count is negative
unsigned data = W1(1);
                ^~~~~
pr5544c.c:2:47: note: instantiated from:
    (((_a) > 31 && (_a) < 64 ? (((unsigned) 1)<<((_a)-32)) : (unsigned) 0))
                                              ^ ~~~~~~~~~
1 warning generated.

Ted Kremenek said about this in bug 5544:

> The underlying problem is not that we don't prune these warnings on paths that
> can be shown to be dead.  The problem here is that Clang doesn't know this
> branch is dead.  The issue is how the CFG models || and && operations.  That's
> worth tracking in a separate 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 May 15 08:11:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 15 May 2011 08:11:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5544] don't emit "shift count is negative" warning
 in dead arm of conditionals
In-Reply-To: <bug-5544-206@http.llvm.org/bugs/>
References: <bug-5544-206@http.llvm.org/bugs/>
Message-ID: <20110515131147.689B22A6C124@llvm.org>

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

Dimitry Andric <dimitry at andric.com> changed:

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

--- Comment #15 from Dimitry Andric <dimitry at andric.com> 2011-05-15 08:11:46 CDT ---
Ted, no problem, sorry for extending the life of this bug yet again. :)

I filed bug 9920 for handling this 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 May 15 10:20:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 15 May 2011 10:20:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9921] New: UNREACHABLE at
 LegalizeIntegerTypes.cpp:982 when using clang's -ftrapv
Message-ID: <bug-9921-206@http.llvm.org/bugs/>

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

           Summary: UNREACHABLE at LegalizeIntegerTypes.cpp:982 when using
                    clang's -ftrapv
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alexei.svitkine at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Compile this code:

long long f(int a, int b)
{
    return (long long)a * (long long)b;
}

Using command-line:

 /usr/local/bin/clang -ftrapv -arch i386 test.c

Result:


ExpandIntegerResult #0: 0x10285cc10: i64,i1 = smulo 0x10285bf10, 0x102862910
[ORD=7] [ID=0]

Do not know how to expand the result of this operator!
UNREACHABLE executed at LegalizeIntegerTypes.cpp:982!
0  clang             0x00000001016ec5e2
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
754
1  clang             0x00000001016ed433
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
4419
2  libSystem.B.dylib 0x00007fff80a9e66a _sigtramp + 26
3  libSystem.B.dylib 0x00007fff5fbfc950 _sigtramp + 3742753536
4  clang             0x00000001016eca06
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
1814
5  clang             0x00000001016d7f2d std::_Rb_tree<std::string,
std::pair<std::string const, void*>, std::_Select1st<std::pair<std::string
const, void*> >, std::less<std::string>, std::allocator<std::pair<std::string
const, void*> >
>::_M_insert_unique(std::_Rb_tree_iterator<std::pair<std::string const, void*>
>, std::pair<std::string const, void*> const&) + 2365
6  clang             0x0000000100f85784
llvm::EVT::getHalfSizedIntegerVT(llvm::LLVMContext&) const + 210996
7  clang             0x0000000100f92015
llvm::TargetLowering::getTypeToExpandTo(llvm::LLVMContext&, llvm::EVT) const +
42773
8  clang             0x0000000100f938ee
llvm::TargetLowering::getTypeToExpandTo(llvm::LLVMContext&, llvm::EVT) const +
49134
9  clang             0x000000010108b737
llvm::FunctionLoweringInfo::InitializeRegForValue(llvm::Value const*) + 48007
10 clang             0x000000010108e3f6
llvm::FunctionLoweringInfo::InitializeRegForValue(llvm::Value const*) + 59462
11 clang             0x000000010108ecd6
llvm::FunctionLoweringInfo::InitializeRegForValue(llvm::Value const*) + 61734
12 clang             0x000000010108f5ac
llvm::FunctionLoweringInfo::InitializeRegForValue(llvm::Value const*) + 63996
13 clang             0x00000001011b4933
llvm::MachineFunctionAnalysis::getPassName() const + 627
14 clang             0x000000010161f200 llvm::BasicBlockPass::~BasicBlockPass()
+ 35648
15 clang             0x000000010161f31b llvm::BasicBlockPass::~BasicBlockPass()
+ 35931
16 clang             0x0000000101620e8f llvm::BasicBlockPass::~BasicBlockPass()
+ 42959
17 clang             0x0000000101621191 llvm::BasicBlockPass::~BasicBlockPass()
+ 43729
18 clang             0x00000001016212ad llvm::BasicBlockPass::~BasicBlockPass()
+ 44013
19 clang             0x000000010019723a clang::PCHGenerator::~PCHGenerator() +
6650
20 clang             0x00000001002d32ae
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 286
21 clang             0x00000001003053b4 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateAdd(llvm::Value*, llvm::Value*, llvm::Twine const&, bool, bool) + 788
22 clang             0x00000001002d19dc
llvm::DenseMap<clang::CodeGen::GlobalDecl, long long,
llvm::DenseMapInfo<clang::CodeGen::GlobalDecl>, llvm::DenseMapInfo<long long>
>::grow(unsigned int) + 2188
23 clang             0x00000001000582a1 llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 8945
24 clang             0x00000001000243b5 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&) + 1893
25 clang             0x000000010001b608
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&) + 9352
26 clang             0x0000000100023572 std::vector<std::string,
std::allocator<std::string> >::operator=(std::vector<std::string,
std::allocator<std::string> > const&) + 12962
27 clang             0x000000010001aa24
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&) + 6308
28 clang             0x0000000000000022
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&) + 4294864546
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
i386-apple-macosx10.6.7 -emit-obj -mrelax-all -disable-free -main-file-name
test.c -pic-level 1 -mdisable-fp-elim -masm-verbose -target-cpu yonah
-target-linker-version 97.17 -resource-dir /usr/local/bin/../lib/clang/3.0
-ferror-limit 19 -fmessage-length 151 -ftrapv -stack-protector 1 -fblocks
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/FO/FOr7SrssHeih0IrqrNZkbE+++TI/-Tmp-/cc-Ij0o1R.o -x c test.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'test.c'.
4.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@f'
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  Sun May 15 12:27:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 15 May 2011 12:27:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9913] Refuses out-of-class definition of class in
 partial specialization
In-Reply-To: <bug-9913-206@http.llvm.org/bugs/>
References: <bug-9913-206@http.llvm.org/bugs/>
Message-ID: <20110515172755.909212A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-15 12:27:55 CDT ---
Fixed in Clang r131383.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 15 14:02:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 15 May 2011 14:02:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9922] New: 'final' pseudo-keyword consumed too
	greedily
Message-ID: <bug-9922-206@http.llvm.org/bugs/>

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

           Summary: 'final' pseudo-keyword consumed too greedily
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: scshunt at csclub.uwaterloo.ca
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following example gives a syntax error:

struct foo { };
struct foo final;

It should instead define a variable final of type struct foo, since this is
legal code if we treat 'final' as a regular identifier.

Note also the following code, once we have brace-initializers, is also a
declaration of a variable named final:

struct foo final { }; 

(Sorry about not having pasted output)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 15 16:34:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 15 May 2011 16:34:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9871] clang crashes in register allocator on PPC
In-Reply-To: <bug-9871-206@http.llvm.org/bugs/>
References: <bug-9871-206@http.llvm.org/bugs/>
Message-ID: <20110515213451.929DA2A6C124@llvm.org>

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

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

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 15 19:49:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 15 May 2011 19:49:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9923] New: enum class streaming causes clang stack
	dump
Message-ID: <bug-9923-206@http.llvm.org/bugs/>

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

           Summary: enum class streaming causes clang stack dump
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I wouldn't have even bothered filing this bug (yet) except that
__has_feature(cxx_strong_enums) answered true in C++0x mode.  So here it is:

Apple clang version 3.0 (trunk 131335) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

$ clang++ -stdlib=libc++ -std=c++0x -I. main.cpp

#include <ostream>

#if __has_feature(cxx_strong_enums)

enum class duration_fmt {prefix, symbol};

#else

struct duration_fmt
{
    enum _ {prefix, symbol};

    _ __v_;

    duration_fmt(_ __v) : __v_(__v) {}
    operator int() const {return __v_;}
};

#endif

template<class charT, class traits>
std::basic_ostream<charT, traits>&
operator <<(std::basic_ostream<charT, traits>& os, duration_fmt d)
{
    return os;
}

#include <iostream>

int main()
{
    std::cout << duration_fmt::symbol;
}


0  clang             0x0000000100cb0f62 PrintStackTrace(void*) + 34
1  clang             0x0000000100cb1419 SignalHandler(int) + 601
2  libSystem.B.dylib 0x00007fff81e0e66a _sigtramp + 26
3  clang             0x00000001001b8443
llvm::FoldingSet<clang::CodeGen::CGFunctionInfo>::NodeEquals(llvm::FoldingSetImpl::Node*,
llvm::FoldingSetNodeID const&, llvm::FoldingSetNodeID&) const + 35
4  clang             0x00000001001bb994 llvm::IRBuilder<false,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<false>
>::CreateLoad(llvm::Value*, char const*) + 52
5  clang             0x0000000100136d4d
clang::CodeGen::CodeGenFunction::EmitLoadOfLValue(clang::CodeGen::LValue,
clang::QualType) + 205
6  clang             0x00000001001533d1 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
10881
7  clang             0x000000010014c598
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 72
8  clang             0x0000000100130b89
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 57
9  clang             0x0000000100131197
clang::CodeGen::CodeGenFunction::EmitAnyExprToTemp(clang::Expr const*) + 183
10 clang             0x000000010010b82b
clang::CodeGen::CodeGenFunction::EmitCallArg(clang::CodeGen::CallArgList&,
clang::Expr const*, clang::QualType) + 123
11 clang             0x0000000100139e6d void
clang::CodeGen::CodeGenFunction::EmitCallArgs<clang::FunctionProtoType>(clang::CodeGen::CallArgList&,
clang::FunctionProtoType const*, clang::ConstExprIterator,
clang::ConstExprIterator) + 109
12 clang             0x00000001001392b3
clang::CodeGen::CodeGenFunction::EmitCall(clang::QualType, llvm::Value*,
clang::CodeGen::ReturnValueSlot, clang::ConstExprIterator,
clang::ConstExprIterator, clang::Decl const*) + 147
13 clang             0x00000001001391f1
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 401
14 clang             0x0000000100133007
clang::CodeGen::CodeGenFunction::EmitCallExprLValue(clang::CallExpr const*) +
39
15 clang             0x0000000100130d03
clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) + 243
16 clang             0x0000000100130b4a
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 58
17 clang             0x000000010018f312
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 194
18 clang             0x0000000100193b4b
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 267
19 clang             0x000000010018f658
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 152
20 clang             0x000000010018f270
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 32
21 clang             0x00000001001aafdf
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 719
22 clang             0x00000001001b0af9
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl)
+ 1881
23 clang             0x00000001001af099
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 393
24 clang             0x00000001001afe6d
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 605
25 clang             0x00000001001b31ec
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 204
26 clang             0x00000001001bd11f (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 95
27 clang             0x00000001001a9771
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 161
28 clang             0x00000001001c4ba2 clang::ParseAST(clang::Sema&, bool) +
290
29 clang             0x00000001001a8adf clang::CodeGenAction::ExecuteAction() +
671
30 clang             0x000000010002935b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 875
31 clang             0x0000000100009738
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2536
32 clang             0x00000001000026a5 cc1_main(char const**, char const**,
char const*, void*) + 5221
33 clang             0x0000000100005fbb main + 667
34 clang             0x0000000100001234 start + 52
Stack dump:
0.    Program arguments:
/Users/hhinnant/Downloads/current-clang/Developer/usr/bin/clang -cc1 -triple
x86_64-apple-macosx10.6.7 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name main.cpp -pic-level 1 -mdisable-fp-elim
-relaxed-aliasing -masm-verbose -munwind-tables -target-cpu core2
-target-linker-version 123.2 -resource-dir
/Users/hhinnant/Downloads/current-clang/Developer/usr/bin/../lib/clang/3.0 -I .
-nostdinc++ -cxx-isystem /usr/include/c++/v1 -std=c++0x -fdeprecated-macro
-ferror-limit 19 -fmessage-length 113 -stack-protector 1 -fblocks
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/9S/9SAm-D9iHUW4BIKyeX7pTE+++TI/-Tmp-/cc-Tl7sdS.o -x c++ main.cpp 
1.    <eof> parser at end of file
2.    main.cpp:30:5: LLVM IR generation of declaration 'main'
3.    main.cpp:30:5: Generating code for declaration 'main'
4.    main.cpp:31:1: LLVM IR generation of compound statement ('{}')
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 May 16 02:23:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 02:23:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9924] New: Programs compiled with clang++ cause GDB
	to segfault
Message-ID: <bug-9924-206@http.llvm.org/bugs/>

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

           Summary: Programs compiled with clang++ cause GDB to segfault
           Product: clang
           Version: 2.9
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: elekktretterr at exemail.com.au
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Hi,

I've been encountering a strange problem in both Clang 2.8 and 2.9. When a
program compiled with Clang create a core dump and the core dump is read with
gdb, gdb itself segfaults and creates a core dump. If try to open gdb's core
dump it segfaults yet again. I've tried different versions of GDB but with same
result.

glock# gdb -v
GNU gdb 6.1.1 [FreeBSD]

glock# clang++ -v
clang version 2.9 (trunk)
Target: x86_64-portbld-freebsd8.2
Thread model: posix

What further information do you need? Does anyone experience a similar problem?

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

From bugzilla-daemon at llvm.org  Mon May 16 04:20:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 04:20:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9925] New: Regression: Invalid point of
 instantiation when using std::string from libc++ in C++0x mode
Message-ID: <bug-9925-206@http.llvm.org/bugs/>

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

           Summary: Regression: Invalid point of instantiation when using
                    std::string from libc++ in C++0x mode
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following program crashes with a failed assertion when compiled with clang
and libc++:

#include <string>

struct Foo {
    std::string    string;
};


int main(int, char**)
{
    Foo    f;
}


clang invocation:

$ clang -std=c++0x -stdlib=libc++ clang.cpp

The failed assertion:

Assertion failed: (Loc.isValid() && "point of instantiation must be valid!"),
function setPointOfInstantiation

My clang version:

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

My libc++ version:

svn info .
[...]
Revision: 131400


The program does *not* crash when C++0x support is disabled.

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

From bugzilla-daemon at llvm.org  Mon May 16 04:48:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 04:48:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9926] New: libclang PCH creation depends on headers
 in the clang/2.9/include subdirectory
Message-ID: <bug-9926-206@http.llvm.org/bugs/>

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

           Summary: libclang PCH creation depends on headers in the
                    clang/2.9/include subdirectory
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pvaucher at infomaniak.ch
                CC: llvmbugs at cs.uiuc.edu


Hello,

It seems that libclang *needs* to find headers in the clang/2.9/include
subdirectory for it to create the automagic PCH cache. If it doens't find those
headers, the cache isn't created and code completion is "slow" everytime (not
only the first time)

We ran some tests with the following code: https://gist.github.com/758615
Here are the results: http://ideone.com/xRXdw

At http://unitedsoft.ch/trace.7z you have a trace of with & without the
headers, we see that it touches & read those headers.

>From a quick digging in the source I couldn't really find what was going on, my
wild guess is that it reads those headers to check wether they're the clang
ones and when they're not it falls back in "safe" mode or smth.

Philippe

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

From bugzilla-daemon at llvm.org  Mon May 16 06:40:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 06:40:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9927] New: crash in objc++ codegen
Message-ID: <bug-9927-206@http.llvm.org/bugs/>

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

           Summary: crash in objc++ codegen
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang crashes in

--------------------
class allocator {
};
class basic_string     {
struct _Alloc_hider : allocator       {
char* _M_p;
};
_Alloc_hider _M_dataplus;
};
@implementation
CrashReporterUI -(void)awakeFromNib {
}
-(void)showCrashUI:(const basic_string&)dumpfile   {
}
@end
----------------------

$ clang -cc1 -emit-llvm-only crashreporter_osx.mii

Assertion failed: (CurOffs <= CurLayObj->first), function
getObjCEncodingForStructureImpl

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

From bugzilla-daemon at llvm.org  Mon May 16 06:52:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 06:52:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9928] New: objective C rewriter doesn't like
	token-pasting
Message-ID: <bug-9928-206@http.llvm.org/bugs/>

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

           Summary: objective C rewriter doesn't like token-pasting
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: madcoder at debian.org
                CC: llvmbugs at cs.uiuc.edu


If you have code with blocks inside macros with token pasting in it, the
rewriter crashes. If you remove the token pasting it works just fine.

In the example below, the 'void (^blk)(void)' is to trigger a rewrite that
results in a crash.

$ cat a.m
#define paste(n) \
    static void _##n(void (^blk)(void)) { }

paste(foo);

$ clang -cc1 -fblocks -rewrite-objc a.m -o a.cc
0  clang           0x00000000019d32bf
1  clang           0x00000000019d3dfa
2  libpthread.so.0 0x00007f79c7ac4020
3  clang           0x0000000000d6de80
4  clang           0x0000000000d6e5a0
5  clang           0x0000000000d7fa5f
6  clang           0x0000000000d802e8
7  clang           0x0000000000d8149f
8  clang           0x00000000008fa6d4 clang::ParseAST(clang::Sema&, bool) + 228
9  clang           0x00000000006a6ba3
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
10 clang           0x000000000067f66a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1290
11 clang           0x000000000067475d cc1_main(char const**, char const**, char
const*, void*) + 701
12 clang           0x000000000067e3b2 main + 6818
13 libc.so.6       0x00007f79c6daaead __libc_start_main + 253
14 clang           0x00000000006742b9
Stack dump:
0.    Program arguments: clang -cc1 -fblocks -rewrite-objc a.m -o a.cc 
1.    a.m:4:11: current parser token ';'
[1]    15995 segmentation fault  clang -cc1 -fblocks -rewrite-objc a.m -o a.cc

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

From bugzilla-daemon at llvm.org  Mon May 16 07:43:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 07:43:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9927] crash in objc++ codegen
In-Reply-To: <bug-9927-206@http.llvm.org/bugs/>
References: <bug-9927-206@http.llvm.org/bugs/>
Message-ID: <20110516124333.408272A6C124@llvm.org>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-05-16 07:43:32 CDT ---
Fixed in 131401.

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

From bugzilla-daemon at llvm.org  Mon May 16 09:57:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 09:57:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9929] New: Regression: Assertion failure in
 getObjCEncodingForStructureImpl
Message-ID: <bug-9929-206@http.llvm.org/bugs/>

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

           Summary: Regression: Assertion failure in
                    getObjCEncodingForStructureImpl
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


I see several crashes when I try to update clang on the chrome bots from 
r130990 to r131395. They look like this:

clang: warning: argument unused during compilation: '-fobjc-exceptions'
CompileC
../../xcodebuild/webkit_support.build/Debug/glue.build/Objects-normal/i386/webmenurunner_mac.o
../glue/webmenurunner_mac.mm normal i386 objective-c++
com.apple.compilers.gcc.4_2
    cd /b/build/slave/mac_clang/build/src/webkit/support
    setenv LANG en_US.US-ASCII
   
/b/build/slave/mac_clang/build/src/third_party/llvm-build/Release+Asserts/bin/clang++
-x objective-c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs
-fno-exceptions -fno-rtti -O0 -Werror -Wnewline-eof -DCHROMIUM_BUILD
-DENABLE_REMOTING=1 -DENABLE_P2P_APIS=1 -DENABLE_GPU=1 -DENABLE_EGLIMAGE=1
-DSK_BUILD_NO_IMAGE_ENCODE -DGR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h"
-DGR_AGGRESSIVE_SHADER_OPTS=1 -DU_USING_ICU_NAMESPACE=0
-DU_STATIC_IMPLEMENTATION -D__STDC_FORMAT_MACROS
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -isysroot
/Developer/SDKs/MacOSX10.5.sdk -fvisibility=hidden -fvisibility-inlines-hidden
-fno-threadsafe-statics -mmacosx-version-min=10.5 -gdwarf-2 -Wall
-Wendif-labels -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-Wheader-hygiene -Wno-char-subscripts -Wno-unused-function
-Wno-unnamed-type-template-args
-F/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/Debug
-F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks
-I/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/Debug/include
-I../../third_party/icu/public/common -I../../third_party/icu/public/i18n
-I/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/DerivedSources/Debug
-I/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/DerivedSources/Debug/webkit
-I../../gpu -I../.. -I../../skia/config -I../../third_party/skia/include/config
-I../../third_party/skia/include/core -I../../third_party/skia/include/effects
-I../../third_party/skia/include/pdf -I../../third_party/skia/include/gpu
-I../../third_party/skia/include/ports -I../../third_party/skia/gpu/include
-I../../skia/ext -I../../third_party/npapi -I../../third_party/npapi/bindings
-I/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/Debug/glue.build/DerivedSources/i386
-I/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/Debug/glue.build/DerivedSources
-fno-strict-aliasing -fobjc-exceptions -Xclang -load -Xclang
/b/build/slave/mac_clang/build/src/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib
-Xclang -add-plugin -Xclang find-bad-constructs -g1 -c
/b/build/slave/mac_clang/build/src/webkit/support/../glue/webmenurunner_mac.mm
-o
/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/Debug/glue.build/Objects-normal/i386/webmenurunner_mac.o

Assertion failed: (CurOffs <= CurLayObj->first), function
getObjCEncodingForStructureImpl, file
/b/build/slave/mac_clang/build/src/third_party/llvm/tools/clang/lib/AST/ASTContext.cpp,
line 4520.
0  clang             0x00000001016ec662 PrintStackTrace(void*) + 34
1  clang             0x00000001016ed4b3 SignalHandler(int) + 707
2  libSystem.B.dylib 0x00007fff8341f66a _sigtramp + 26
3  libSystem.B.dylib 0x00000001060fc080 _sigtramp + 2194524720
4  clang             0x00000001000197d2 __assert_rtn + 66
5  clang             0x00000001008838d1
clang::ASTContext::getObjCEncodingForStructureImpl(clang::RecordDecl*,
std::string&, clang::FieldDecl const*, bool) const + 3777
6  clang             0x0000000100882810
clang::ASTContext::getObjCEncodingForTypeImpl(clang::QualType, std::string&,
bool, bool, clang::FieldDecl const*, bool, bool, bool) const + 7328
7  clang             0x000000010088340e
clang::ASTContext::getObjCEncodingForStructureImpl(clang::RecordDecl*,
std::string&, clang::FieldDecl const*, bool) const + 2558
8  clang             0x00000001008831b7
clang::ASTContext::getObjCEncodingForStructureImpl(clang::RecordDecl*,
std::string&, clang::FieldDecl const*, bool) const + 1959
9  clang             0x0000000100882810
clang::ASTContext::getObjCEncodingForTypeImpl(clang::QualType, std::string&,
bool, bool, clang::FieldDecl const*, bool, bool, bool) const + 7328
10 clang             0x0000000100881440
clang::ASTContext::getObjCEncodingForTypeImpl(clang::QualType, std::string&,
bool, bool, clang::FieldDecl const*, bool, bool, bool) const + 2256
11 clang             0x0000000100884dde
clang::ASTContext::getObjCEncodingForMethodDecl(clang::ObjCMethodDecl const*,
std::string&) const + 1278
12 clang             0x00000001002740c6 (anonymous
namespace)::CGObjCCommonMac::GetMethodVarType(clang::ObjCMethodDecl const*) +
70
13 clang             0x000000010027f29c (anonymous
namespace)::CGObjCMac::GetMethodConstant(clang::ObjCMethodDecl const*) + 204
14 clang             0x0000000100292299 (anonymous
namespace)::CGObjCMac::GenerateClass(clang::ObjCImplementationDecl const*) +
969
15 clang             0x00000001002e5019
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 1657
16 clang             0x00000001002f840f (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 63
17 clang             0x00000001002d320b
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 155
18 clang             0x0000000100089ce1
clang::MultiplexConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 65
19 clang             0x00000001003050f2 clang::ParseAST(clang::Sema&, bool) +
322
20 clang             0x00000001002d178c clang::CodeGenAction::ExecuteAction() +
60
21 clang             0x00000001000577a1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 433
22 clang             0x00000001000238b5
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1493
23 clang             0x000000010001ab08 cc1_main(char const**, char const**,
char const*, void*) + 568
24 clang             0x0000000100022a72 main + 4946
25 clang             0x0000000100019f24 start + 52
26 clang             0x0000000000000080 start + 4294861200
Stack dump:
0.    Program arguments:
/b/build/slave/mac_clang/build/src/third_party/llvm-build/Release+Asserts/bin/clang
-cc1 -triple i386-apple-macosx10.5.0 -emit-obj -mrelax-all -disable-free
-main-file-name webmenurunner_mac.mm -pic-level 1 -mdisable-fp-elim
-relaxed-aliasing -masm-verbose -target-cpu yonah -target-linker-version 97.2
-g -coverage-file
/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/Debug/glue.build/Objects-normal/i386/webmenurunner_mac.o
-resource-dir
/b/build/slave/mac_clang/build/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.0
-isysroot /Developer/SDKs/MacOSX10.5.sdk -D CHROMIUM_BUILD -D ENABLE_REMOTING=1
-D ENABLE_P2P_APIS=1 -D ENABLE_GPU=1 -D ENABLE_EGLIMAGE=1 -D
SK_BUILD_NO_IMAGE_ENCODE -D GR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h" -D
GR_AGGRESSIVE_SHADER_OPTS=1 -D U_USING_ICU_NAMESPACE=0 -D
U_STATIC_IMPLEMENTATION -D __STDC_FORMAT_MACROS -D
DYNAMIC_ANNOTATIONS_ENABLED=1 -D WTF_USE_DYNAMIC_ANNOTATIONS=1
-F/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/Debug
-F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks
-I
/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/Debug/include
-I ../../third_party/icu/public/common -I ../../third_party/icu/public/i18n -I
/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/DerivedSources/Debug
-I
/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/DerivedSources/Debug/webkit
-I ../../gpu -I ../.. -I ../../skia/config -I
../../third_party/skia/include/config -I ../../third_party/skia/include/core -I
../../third_party/skia/include/effects -I ../../third_party/skia/include/pdf -I
../../third_party/skia/include/gpu -I ../../third_party/skia/include/ports -I
../../third_party/skia/gpu/include -I ../../skia/ext -I ../../third_party/npapi
-I ../../third_party/npapi/bindings -I
/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/Debug/glue.build/DerivedSources/i386
-I
/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/Debug/glue.build/DerivedSources
-O0 -Wno-trigraphs -Werror -Wnewline-eof -Wall -Wendif-labels -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -Wheader-hygiene
-Wno-char-subscripts -Wno-unused-function -Wno-unnamed-type-template-args
-fdeprecated-macro -ferror-limit 19 -fmessage-length 0 -fvisibility hidden
-fvisibility-inlines-hidden -fblocks -fobjc-exceptions -fno-rtti
-fno-threadsafe-statics -fdiagnostics-show-option -load
/b/build/slave/mac_clang/build/src/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib
-add-plugin find-bad-constructs -o
/b/build/slave/mac_clang/build/src/webkit/support/../../xcodebuild/webkit_support.build/Debug/glue.build/Objects-normal/i386/webmenurunner_mac.o
-x objective-c++
/b/build/slave/mac_clang/build/src/webkit/support/../glue/webmenurunner_mac.mm 
1.   
/b/build/slave/mac_clang/build/src/webkit/support/../glue/webmenurunner_mac.mm:159:1:
current parser token 'namespace'
2.   
/b/build/slave/mac_clang/build/src/webkit/support/../glue/webmenurunner_mac.mm:42:1:
LLVM IR generation of declaration 'WebMenuRunner'
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 May 16 09:58:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 09:58:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9929] Regression: Assertion failure in
 getObjCEncodingForStructureImpl
In-Reply-To: <bug-9929-206@http.llvm.org/bugs/>
References: <bug-9929-206@http.llvm.org/bugs/>
Message-ID: <20110516145832.C661E2A6C124@llvm.org>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #1 from Nico Weber <nicolasweber at gmx.de> 2011-05-16 09:58:32 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon May 16 10:28:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 10:28:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9930] New: false positive garbage value when set
	from cast.
Message-ID: <bug-9930-206@http.llvm.org/bugs/>

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

           Summary: false positive garbage value when set from cast.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: kenny.macdermid at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6600)
 --> (http://llvm.org/bugs/attachment.cgi?id=6600)
Example file generating error (gcc -O0 -std=c99)

When using a uint8_t and setting the value from with something like:
"((uint32_t *)randbuf)[i] = rand();" the static analyzer appears to think that
randbuf[2] is not set.

The reported error is: The left operand of '&' is a garbage value 

Attached are a test case and the generated report.

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

From bugzilla-daemon at llvm.org  Mon May 16 10:37:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 10:37:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9928] objective C rewriter doesn't like
	token-pasting
In-Reply-To: <bug-9928-206@http.llvm.org/bugs/>
References: <bug-9928-206@http.llvm.org/bugs/>
Message-ID: <20110516153723.84AFA2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-16 10:37:22 CDT ---
The Objective-C rewriter is intended to be an example of rewriter technology,
not a generally useful clang tool.  I would strongly recommend not using it for
anything important.

-Chris

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

From bugzilla-daemon at llvm.org  Mon May 16 20:12:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 20:12:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9931] New: Assertion `L->isLCSSAForm(*DT)' failed.
Message-ID: <bug-9931-206@http.llvm.org/bugs/>

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

           Summary: Assertion `L->isLCSSAForm(*DT)' failed.
           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: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


[regehr at gamow tmp023]$ clang -c -O3 small.c -w
clang: LCSSA.cpp:160: virtual bool<unnamed>::LCSSA::runOnLoop(llvm::Loop*,
llvm::LPPassManager&): Assertion `L->isLCSSAForm(*DT)' failed.
0  clang           0x00000000018f2aef
1  clang           0x00000000018f4d62
2  libpthread.so.0 0x00007ffff7bcf8f0
3  libc.so.6       0x00007ffff6ebea75 gsignal + 53
4  libc.so.6       0x00007ffff6ec25c0 abort + 384
5  libc.so.6       0x00007ffff6eb7941 __assert_fail + 241
6  clang           0x000000000169d7a3
7  clang           0x0000000001714f24
llvm::LPPassManager::runOnFunction(llvm::Function&) + 1252
8  clang           0x000000000183f30b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 587
9  clang           0x00000000016d4c6d
10 clang           0x000000000183ee07
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
11 clang           0x000000000183ef9b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
12 clang           0x00000000007c8f38
13 clang           0x00000000007c9bbd
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 189
14 clang           0x00000000007c65ab
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
15 clang           0x00000000008f7cad clang::ParseAST(clang::Sema&, bool) + 413
16 clang           0x00000000007c58f4 clang::CodeGenAction::ExecuteAction() +
68
17 clang           0x00000000006b1873
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
18 clang           0x0000000000688f14
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1268
19 clang           0x000000000067fdcb cc1_main(char const**, char const**, char
const*, void*) + 683
20 clang           0x0000000000687d67 main + 6295
21 libc.so.6       0x00007ffff6ea9c4d __libc_start_main + 253
22 clang           0x000000000067e299
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r131444-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -coverage-file small.o -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r131444-install/bin/../lib/clang/3.0
-O3 -w -ferror-limit 19 -fmessage-length 83 -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_16'
5.    Running pass 'Loop-Closed SSA Form Pass' on basic block
'%for.cond2.preheader.i.us'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)
[regehr at gamow tmp023]$ clang -v
clang version 3.0 (trunk 131444)
Target: x86_64-unknown-linux-gnu
Thread model: posix
[regehr at gamow tmp023]$ cat small.c
static int
safe_26 (int si1, int si2)
{
  return si2 == 0 || si1 == 1 && si2 == 1 ? 1 : si1 / si2;
}

struct S0
{
  short f0;
  short f1;
};
int g_3[] = {
};

struct S0 g_191 = {
};

int g_471[] = {
};

int *func_20 (int, unsigned long long);
char
func_16 (unsigned short p_17, unsigned long long p_18,
     unsigned long long p_19)
{
  func_20 (g_3[1], 0);
  return 0;
}

int *
func_20 (int p_21, unsigned long long p_22)
{
  long l_446[] = {
    1, 0,
  };
  for (; g_191.f1; g_191.f1 -= 1)
    for (g_191.f0 = 0; g_191.f0 <= 4; g_191.f0 += 1)
      {
    int *l_470 = &g_471[0];
    *l_470 ^= safe_26 (l_446[0] | l_446[g_191.f0], p_21);
      }
  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  Mon May 16 21:06:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 21:06:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5375] Too many redundant neon / vfp reg-reg moves
	are generated
In-Reply-To: <bug-5375-206@http.llvm.org/bugs/>
References: <bug-5375-206@http.llvm.org/bugs/>
Message-ID: <20110517020639.11E5D2A6C12F@llvm.org>

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

Evan Cheng <evan.cheng at apple.com> changed:

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

--- Comment #3 from Evan Cheng <evan.cheng at apple.com> 2011-05-16 21:06:38 CDT ---
Seems fixed now.

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

From bugzilla-daemon at llvm.org  Mon May 16 21:50:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 16 May 2011 21:50:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9932] New: BX LR does not work in Thumb
Message-ID: <bug-9932-206@http.llvm.org/bugs/>

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

           Summary: BX LR does not work in Thumb
           Product: libraries
           Version: 2.9
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

BX LR is a rather important instruction, but it does not work in Thumb mode.
Here is my output. I am targeting Cortex-M3.

C:\Code\src\thirdp\llvm-bin\bin\Release>llc -march=thumb -mattr=+thumb2
-filetype=obj -o testme.x te
stme.s
<inline asm>:2:4: error: invalid operand for instruction
it vs
   ^
<inline asm>:4:1: error: instruction requires a CPU feature not currently
enabled
bx lr
^
LLVM ERROR: Error parsing inline asm

Stack dump:
0.      Program arguments: llc -march=thumb -mattr=+thumb2 -filetype=obj -o
testme.x testme.s
1.      Running pass 'Function Pass Manager' on module 'testme.s'.
2.      Running pass 'ARM Assembly Printer' on function '@test'

For what it's worth, IT VS also appears to not work (it doesn't even understand
the *instruction* ITT)...

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

From bugzilla-daemon at llvm.org  Tue May 17 01:52:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 01:52:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9933] New: ShouldDisableCFI logic can break ELF
	kernel build
Message-ID: <bug-9933-206@http.llvm.org/bugs/>

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

           Summary: ShouldDisableCFI logic can break ELF kernel build
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


At the moment, building with -mcmodel=kernel and -no-integrated-as disables the
use of .cfi* instructions. The explicitly generated .eh_frame section fails
linking.

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

From bugzilla-daemon at llvm.org  Tue May 17 02:00:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 02:00:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9934] New: Assembler parser gives wrong relocations
	for $foo
Message-ID: <bug-9934-206@http.llvm.org/bugs/>

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

           Summary: Assembler parser gives wrong relocations for $foo
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


In NetBSD's Xen code, the following can be found:

    addq $hypercall_page,%rax

With llvm-mc, this gets turned into:

   0:    48 81 c0 00 00 00 00     add    $0x0,%rax
            3: R_X86_64_32    hypercall_page

GNU as gives:

   0:    48 05 00 00 00 00        add    $0x0,%rax
            2: R_X86_64_32S    hypercall_page

The former fails to link.

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

From bugzilla-daemon at llvm.org  Tue May 17 12:09:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 12:09:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9935] New: insertvalue syntax in Language Reference
 Manual does not show it being vararg.
Message-ID: <bug-9935-206@http.llvm.org/bugs/>

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

           Summary: insertvalue syntax in Language Reference Manual does
                    not show it being vararg.
           Product: Documentation
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: michael at lunarg.com
                CC: llvmbugs at cs.uiuc.edu


The reference manual for the insertvalue[1] instruction, shows the syntax of
inservalue as being
 "<result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx>    ; yields
<aggregate type>", 
while the syntax for extractvalue is 
"<result> = extractvalue <aggregate type> <val>, <idx>{, <idx>}*"

The description of the arguments for insertvalue implies that the syntax for
should be vararg like extractvalue.
"The first operand of an 'insertvalue' instruction is a value of struct or
array type. The second operand is a first-class value to insert. The following
operands are constant indices indicating the position at which to insert the
value in a similar manner as indices in a 'extractvalue' instruction. The value
to insert must have the same type as the value identified by the indices."

Code in Instructions.h seems to treat insertelement as being vararg in the
indices.

[1] http://llvm.org/docs/LangRef.html#i_insertvalue

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

From bugzilla-daemon at llvm.org  Tue May 17 13:50:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 13:50:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9936] New: Incorrect statement ambiguity resolution
 for declaration with template-id
Message-ID: <bug-9936-206@http.llvm.org/bugs/>

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

           Summary: Incorrect statement ambiguity resolution for
                    declaration with template-id
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I think the following should be a local declaration of "A<int>" and be
ill-formed:

template<typename T>
int f();

int main() {
  int(f<int>());
  // same as:
  // int f<int>();
}

Clang parses it as though it would be a functional cast.

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

From bugzilla-daemon at llvm.org  Tue May 17 14:03:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 14:03:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9937] New: Incorrect parse of simple-declaration
 containing two type-name template-ids
Message-ID: <bug-9937-206@http.llvm.org/bugs/>

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

           Summary: Incorrect parse of simple-declaration containing two
                    type-name template-ids
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following parses incorrectly in Clang:

template<typename T>
struct A { };

namespace N {
A<int> A<int>();
}

The second "A<int>" should not belong to the decl-specifier-seq, but to the
init-declarator, and be the declarator-id of the simple-declaration.

It can be argued what the better error message ("cannot combine with previous
'type-name' declaration specifier" as it is now, or "template specialization
requires 'template<>'" as it would if clang would parse it correctly), but it
should be considered:

- Is the existing diagnostic better than what we would get if we parsed it
correctly? Are both equally bad?
- Can there be well-formed code that would be made ill-formed by the current
parse? (I can't think of any).
- Is the advantage of having a better diagnostic worth parsing this and other
(afaics) ill-formed code the way it's parsed?

I don't have strong opinions about this, but I thought I would open a PR about
it, so it can be considered generally :)

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

From bugzilla-daemon at llvm.org  Tue May 17 17:21:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 17:21:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9914] Clang crashes in Globals.cpp
In-Reply-To: <bug-9914-206@http.llvm.org/bugs/>
References: <bug-9914-206@http.llvm.org/bugs/>
Message-ID: <20110517222156.943AC2A6C124@llvm.org>

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

Fariborz Jahanian <fjahanian at apple.com> changed:

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

--- Comment #7 from Fariborz Jahanian <fjahanian at apple.com> 2011-05-17 17:21:55 CDT ---
Fixed in r131496

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

From bugzilla-daemon at llvm.org  Tue May 17 19:53:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 19:53:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9938] New: Implicit copy assignment exception spec
	not enforced
Message-ID: <bug-9938-206@http.llvm.org/bugs/>

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

           Summary: Implicit copy assignment exception spec not enforced
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: scshunt at csclub.uwaterloo.ca
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code should not execute successfully:


struct A{ };
struct B{ };

struct foo {
  void operator=(const foo&) throw(B) {}
};

struct bar {
  bar& operator = (const bar&) {
    throw A();
  }
};

struct baz : foo {
  bar b;
};

int main() {
  try {
    baz bb;
    bb = bb;
  } catch (...) { }
}


What should happen is that bar's copy assignment operator gets an implicit
throw spec of throw(B), then terminate() is called when the A exception object
attempts to leave it. Instead, we don't even generate an unexpected exception
trampoline for baz' copy assignment.

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

From bugzilla-daemon at llvm.org  Tue May 17 20:03:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 20:03:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9939] New: Loop strength reduction breaks this test
Message-ID: <bug-9939-206@http.llvm.org/bugs/>

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

           Summary: Loop strength reduction breaks this test
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

Loop strength reduction is breaking firefox's test_jsctypes.js.

I reduced the problem to the attached testcase, but haven't been able to find
the bug itself yet. Looks like what it gets wrong is the compensation added
when the loop condition is converted from 

        cmpq    %r9, %rdx
        jne     .LBB0_4
to

        addq    $-2, %rcx
        jne     .LBB0_4

I checked that building with " -Xclang -mllvm -Xclang -disable-lsr" added
causes the original test to pass.

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

From bugzilla-daemon at llvm.org  Tue May 17 22:40:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 22:40:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9940] New: Strange error with function pointer
 variable and function template with same name
Message-ID: <bug-9940-206@http.llvm.org/bugs/>

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

           Summary: Strange error with function pointer variable and
                    function template with same name
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Testcase:
template<typename T> int f();
int main() {
  int((*f)())(f<int>); f();
}

clang gives:
<stdin>:5:15: error: use of undeclared identifier 'f'
  int((*f)())(f<int>); f();
              ^

I'm not entirely sure whether this is valid, but claiming that f is undeclared
is confusing at best.

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

From bugzilla-daemon at llvm.org  Tue May 17 22:42:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 17 May 2011 22:42:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9917] Crash by including libc++ <valarray> in c++0x
	mode
In-Reply-To: <bug-9917-206@http.llvm.org/bugs/>
References: <bug-9917-206@http.llvm.org/bugs/>
Message-ID: <20110518034225.863C42A6C124@llvm.org>

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

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

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

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

From bugzilla-daemon at llvm.org  Wed May 18 07:21:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 07:21:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9941] New: Error in simple code in C++0x: exception
 specification of overriding function is more lax than base version
Message-ID: <bug-9941-206@http.llvm.org/bugs/>

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

           Summary: Error in simple code in C++0x: exception specification
                    of overriding function is more lax than base version
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code fails to compile with -std=c++0x

struct X
{ virtual ~X() {} };

struct Y : X
{ virtual ~Y() {} };

with the error message:

t.cc:5:11: error: exception specification of overriding function is more lax
      than base version
{ virtual ~Y() {} };
          ^
t.cc:2:11: note: overridden virtual function is here
{ virtual ~X() {} };

This is currently blocking libc++, and mostly anything 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  Wed May 18 07:44:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 07:44:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9942] New: error: exception specification of
 overriding function is more lax than base version
Message-ID: <bug-9942-206@http.llvm.org/bugs/>

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

           Summary: error: exception specification of overriding function
                    is more lax than base version
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

class __shared_count
{
protected:
    virtual ~__shared_count();
};

class __shared_weak_count
    : private __shared_count
{
protected:
    virtual ~__shared_weak_count();
};


test.cpp:11:13: error: exception specification of overriding function is more
lax than base version
    virtual ~__shared_weak_count();
            ^
test.cpp:4:13: note: overridden virtual function is here
    virtual ~__shared_count();
            ^
1 error generated.


Apple clang version 3.0 (trunk 131530) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

This error is severe enough that libc++ is completely unusable.  I'm reverting
to an earlier build.

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

From bugzilla-daemon at llvm.org  Wed May 18 14:16:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 14:16:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9943] New: x86 sibcall logic mis-understands 'byval'
Message-ID: <bug-9943-206@http.llvm.org/bugs/>

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

           Summary: x86 sibcall logic mis-understands 'byval'
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stuart at apple.com
                CC: llvmbugs at cs.uiuc.edu


A not-yet-applied patch to the x86_64 byval logic will teach it to pass tiny
byval structs in registers as required by the x86_64 ABI.  This has exposed a
misconception in the x86 sibcall logic; it thinks that 'byval' means "passed in
memory."  The upshot is that an incorrect sibcall can be generated if one of
the parameters is a byval struct that is passed in registers.

This is fairly academic, as all existing front-ends I know of will only use
byval on large structs that will never be passed in registers.  However, it's
possible to write a legal LLVM testcase that exposes this flaw.

Here is such a test case:

; rdar://r7717598                                                               
%struct.ns = type { i32, i32 }
%struct.cp = type { float, float }

define %struct.ns* @t13(%struct.cp* %yy) nounwind ssp {
; 32: t13:                                                                      
; 32-NOT: jmp                                                                   
; 32: calll                                                                     
; 32: ret                                                                       

; 64: t13:                                                                      
; 64-NOT: jmp                                                                   
; 64: callq                                                                     
; 64: ret                                                                       
entry:
  %0 = tail call fastcc %struct.ns* @foo7(%struct.cp* byval align 4 %yy, i8
signext 0) nounwind
  ret %struct.ns* %0
}

This was extracted from test/CodeGen/X86/sibcall.ll.

Before I apply my byval patch, I will commit a change to the original test
case; I'll make %struct.cp larger, so it will always be passed in memory.  (The
original version is above.)

Once this flaw in the sibcall logic is fixed, we can revert my workaround patch
to sibcall.ll.

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

From bugzilla-daemon at llvm.org  Wed May 18 14:46:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 14:46:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9944] New: Doesn't SFINAE away an invalid
 substitution into toplevel parameter type "T[N]"
Message-ID: <bug-9944-206@http.llvm.org/bugs/>

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

           Summary: Doesn't SFINAE away an invalid substitution into
                    toplevel parameter type "T[N]"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


GCC incorrectly fails to compile this code

template<typename T> void f(T[1]) = delete; 
template<typename T> void f(...); 
int main() { f<void>(0); }

The substitution into "T" should fail, because "T[1]" is an invalid type, and
hence the call should use the second template. 

Note that I think it's unspecified in the spec what happens when we tweak
things as follows

template<typename T> void f(T[1]) = delete; 
template<typename T> void f(T*);
template<typename T> void f(...); 
int main() { f<void>(0); }

The first two templates are equivalent, but behave different during
substitution. The spec doesn't specify what the outcome of this is, I think.

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

From bugzilla-daemon at llvm.org  Wed May 18 14:47:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 14:47:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9944] Doesn't SFINAE away an invalid substitution
 into toplevel parameter type "T[N]"
In-Reply-To: <bug-9944-206@http.llvm.org/bugs/>
References: <bug-9944-206@http.llvm.org/bugs/>
Message-ID: <20110518194715.684D02A6C124@llvm.org>

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

Johannes Schaub <schaub.johannes at googlemail.com> changed:

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

--- Comment #1 from Johannes Schaub <schaub.johannes at googlemail.com> 2011-05-18 14:47:15 CDT ---
sorry, this should have been sent to GCC. Silly me.

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

From bugzilla-daemon at llvm.org  Wed May 18 15:09:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 15:09:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9938] Implicit copy assignment exception spec not
	enforced
In-Reply-To: <bug-9938-206@http.llvm.org/bugs/>
References: <bug-9938-206@http.llvm.org/bugs/>
Message-ID: <20110518200943.B97AC2A6C124@llvm.org>

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

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

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

--- Comment #2 from Sean Hunt <scshunt at csclub.uwaterloo.ca> 2011-05-18 15:09:43 CDT ---
Oops

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

From bugzilla-daemon at llvm.org  Wed May 18 15:10:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 15:10:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9942] error: exception specification of overriding
 function is more lax than base version
In-Reply-To: <bug-9942-206@http.llvm.org/bugs/>
References: <bug-9942-206@http.llvm.org/bugs/>
Message-ID: <20110518201002.F11072A6C124@llvm.org>

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

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

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

--- Comment #1 from Sean Hunt <scshunt at csclub.uwaterloo.ca> 2011-05-18 15:10:02 CDT ---
Duplicate of 9941.

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

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

From bugzilla-daemon at llvm.org  Wed May 18 16:11:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 16:11:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9945] New: -ftrapv triggers "fatal error: error in
 backend: Cannot select: 0x7f833b2cdc10: i8 = setcc 0x7f833b2c1710,
 0x7f833b2cd110, 0x7f833b2cf610 [ID=44] "
Message-ID: <bug-9945-206@http.llvm.org/bugs/>

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

           Summary: -ftrapv triggers "fatal error: error in backend:
                    Cannot select: 0x7f833b2cdc10: i8 = setcc
                    0x7f833b2c1710, 0x7f833b2cd110, 0x7f833b2cf610 [ID=44]
                    "
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mayer.julian at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6607)
 --> (http://llvm.org/bugs/attachment.cgi?id=6607)
source file that triggers the problem

trying to compile instrinic.cpp (attached) with -ftrapv yields the following: 


noname:FastDXT julian$ clang -ftrapv intrinsic.cpp 
fatal error: error in backend: Cannot select: 0x7f833b2cdc10: i8 = setcc
0x7f833b2c1710, 0x7f833b2cd110, 0x7f833b2cf610 [ID=44]
  0x7f833b2c1710: v8i16 = sub 0x7f833b2b5d10, 0x7f833b2d2110 [ID=41]
    0x7f833b2b5d10: v8i16 = bitcast 0x7f833b2d1010 [ID=39]
      0x7f833b2d1010: v2i64,ch = load 0x7f833b2b2f10, 0x7f833b2c2e10,
0x7f833b2d1a10<LD16[%3]> [ID=38]
        0x7f833b2c2e10: i64 = FrameIndex<2> [ORD=324] [ID=7]
        0x7f833b2d1a10: i64 = undef [ORD=319] [ID=4]
    0x7f833b2d2110: v8i16 = bitcast 0x7f833b2d1410 [ID=35]
      0x7f833b2d1410: v2i64,ch = load 0x7f833b2b4610, 0x7f833b2c2810,
0x7f833b2d1a10<LD16[%t0]> [ORD=323] [ID=33]
        0x7f833b2c2810: i64 = FrameIndex<49> [ORD=323] [ID=6]
        0x7f833b2d1a10: i64 = undef [ORD=319] [ID=4]
  0x7f833b2cd110: v8i16 = bitcast 0x7f833b2cd310 [ID=23]
    0x7f833b2cd310: v4i32 = BUILD_VECTOR 0x7f833b2cd410, 0x7f833b2cd410,
0x7f833b2cd410, 0x7f833b2cd410 [ID=20]
      0x7f833b2cd410: i32 = TargetConstant<0> [ID=14]
      0x7f833b2cd410: i32 = TargetConstant<0> [ID=14]
      0x7f833b2cd410: i32 = TargetConstant<0> [ID=14]
      0x7f833b2cd410: i32 = TargetConstant<0> [ID=14]


happens with the clang versions from Xcode 4.0 and Xcode 4.1b5

instrinic.cpp 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  Wed May 18 16:23:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 16:23:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9939] Loop strength reduction breaks this test
In-Reply-To: <bug-9939-206@http.llvm.org/bugs/>
References: <bug-9939-206@http.llvm.org/bugs/>
Message-ID: <20110518212309.A55182A6C12D@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #3 from Dan Gohman <gohman at apple.com> 2011-05-18 16:23:09 CDT ---
What a tricky testcase! Fixed in r131576.

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

From bugzilla-daemon at llvm.org  Wed May 18 17:00:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 17:00:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9892] clang can miscompile GNU gettext's xgettext.c
In-Reply-To: <bug-9892-206@http.llvm.org/bugs/>
References: <bug-9892-206@http.llvm.org/bugs/>
Message-ID: <20110518220050.4147E2A6C124@llvm.org>

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

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

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

--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com> 2011-05-18 17:00:49 CDT ---
I can't reproduce it anymore. This was probably fixed by Dan's r131576.

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

From bugzilla-daemon at llvm.org  Wed May 18 17:29:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 17:29:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8827] MachineVerifier complains about undefined
 physical registers at segment register uses
In-Reply-To: <bug-8827-206@http.llvm.org/bugs/>
References: <bug-8827-206@http.llvm.org/bugs/>
Message-ID: <20110518222943.8C40E2A6C12D@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #1 from Cameron Zwarich <zwarich at apple.com> 2011-05-18 17:29:43 CDT ---
Fixed in r131591.

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

From bugzilla-daemon at llvm.org  Wed May 18 17:32:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 17:32:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8826] MachineVerifier complains about undefined
 physical registers at implicit uses
In-Reply-To: <bug-8826-206@http.llvm.org/bugs/>
References: <bug-8826-206@http.llvm.org/bugs/>
Message-ID: <20110518223222.D7BDD2A6C12D@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #2 from Cameron Zwarich <zwarich at apple.com> 2011-05-18 17:32:22 CDT ---
Fixed in r131587.

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

From bugzilla-daemon at llvm.org  Wed May 18 17:33:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 17:33:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8812] Verifier complains about missing kill flags
 on subregisters
In-Reply-To: <bug-8812-206@http.llvm.org/bugs/>
References: <bug-8812-206@http.llvm.org/bugs/>
Message-ID: <20110518223336.8F5A22A6C124@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #2 from Cameron Zwarich <zwarich at apple.com> 2011-05-18 17:33:36 CDT ---
This somehow fixed itself.

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

From bugzilla-daemon at llvm.org  Wed May 18 19:40:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 19:40:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9945] -ftrapv triggers "fatal error: error in
 backend: Cannot select: 0x7f833b2cdc10: i8 = setcc 0x7f833b2c1710,
 0x7f833b2cd110, 0x7f833b2cf610 [ID=44] "
In-Reply-To: <bug-9945-206@http.llvm.org/bugs/>
References: <bug-9945-206@http.llvm.org/bugs/>
Message-ID: <20110519004007.7E1F62A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-18 19:40:06 CDT ---
r131611.

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

From bugzilla-daemon at llvm.org  Wed May 18 20:56:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 20:56:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9946] New: crash in simplifycfg
Message-ID: <bug-9946-206@http.llvm.org/bugs/>

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

           Summary: crash in simplifycfg
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

opt -simplifycfg will crash in the attached test.

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

From bugzilla-daemon at llvm.org  Wed May 18 21:19:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 21:19:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8825] MachineVerifier gives ARM register class
 mismatch errors on tests
In-Reply-To: <bug-8825-206@http.llvm.org/bugs/>
References: <bug-8825-206@http.llvm.org/bugs/>
Message-ID: <20110519021932.C24372A6C12D@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #12 from Cameron Zwarich <zwarich at apple.com> 2011-05-18 21:19:32 CDT ---
Last bit fixed in r131619.

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

From bugzilla-daemon at llvm.org  Wed May 18 21:36:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 21:36:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9946] crash in simplifycfg
In-Reply-To: <bug-9946-206@http.llvm.org/bugs/>
References: <bug-9946-206@http.llvm.org/bugs/>
Message-ID: <20110519023614.58BB62A6C124@llvm.org>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-05-18 21:36:14 CDT ---
This was 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 May 18 21:56:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 21:56:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8828] MachineVerifier complains about MovePCtoLR
In-Reply-To: <bug-8828-206@http.llvm.org/bugs/>
References: <bug-8828-206@http.llvm.org/bugs/>
Message-ID: <20110519025643.AC82A2A6C124@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #3 from Cameron Zwarich <zwarich at apple.com> 2011-05-18 21:56:43 CDT ---
Fixed in r131626.

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

From bugzilla-daemon at llvm.org  Wed May 18 23:49:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 18 May 2011 23:49:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9947] New: Instruction selection places memory
 operands on the wrong instructions
Message-ID: <bug-9947-206@http.llvm.org/bugs/>

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

           Summary: Instruction selection places memory operands on the
                    wrong instructions
           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: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


It appears that for some patterns, isel puts the memory operands on the wrong
MachineInstructions. All of the remaining verifier failures in the "make check"
tests are due to this problem. Here is a simple example:

********************
FAIL: LLVM :: CodeGen/X86/break-sse-dep.ll (2322 of 6038)
******************** TEST 'LLVM :: CodeGen/X86/break-sse-dep.ll' FAILED
********************
Script:
--
/Volumes/Data/b/Release+Asserts/bin/llc <
/Volumes/Data/l/test/CodeGen/X86/break-sse-dep.ll -mtriple=x86_64-linux
-mattr=+sse2 | /Volumes/Data/b/Release+Asserts/bin/FileCheck
/Volumes/Data/l/test/CodeGen/X86/break-sse-dep.ll
/Volumes/Data/b/Release+Asserts/bin/llc <
/Volumes/Data/l/test/CodeGen/X86/break-sse-dep.ll -mtriple=x86_64-win32
-mattr=+sse2 | /Volumes/Data/b/Release+Asserts/bin/FileCheck
/Volumes/Data/l/test/CodeGen/X86/break-sse-dep.ll
--
Exit Code: 1
Command Output (stderr):
--

# Before register coalescing
# Machine code for function t1:
Function Live Ins: %RDI in %vreg0
Function Live Outs: %XMM0

0L    BB#0: derived from LLVM BB %entry
        Live Ins: %RDI
16L        %vreg0<def> = COPY %RDI<kill>; GR64:%vreg0
32L        %vreg1<def> = MOVSSrm %vreg0<kill>, 1, %noreg, 0, %noreg;
FR32:%vreg1 GR64:%vreg0
48L        %vreg2<def> = CVTSS2SDrr %vreg1<kill>; mem:LD4[%x] FR64:%vreg2
FR32:%vreg1
64L        %XMM0<def> = COPY %vreg2<kill>; FR64:%vreg2
80L        RET %XMM0<imp-use,kill>

# End machine code for function t1.

*** Bad machine code: Missing mayLoad flag ***
- function:    t1
- basic block: entry 0x7fc41b0337a0 (BB#0) [0L;96L)
- instruction: 48L    %vreg2<def> = CVTSS2SDrr %vreg1<kill>; mem:LD4[%x]
FR64:%vreg2 FR32:%vreg1
LLVM ERROR: Found 1 machine code 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  Thu May 19 00:14:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 00:14:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9941] Error in simple code in C++0x: exception
 specification of overriding function is more lax than base version
In-Reply-To: <bug-9941-206@http.llvm.org/bugs/>
References: <bug-9941-206@http.llvm.org/bugs/>
Message-ID: <20110519051447.CB4852A6C124@llvm.org>

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

Sebastian Redl <sebastian.redl at getdesigned.at> changed:

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

--- Comment #3 from Sebastian Redl <sebastian.redl at getdesigned.at> 2011-05-19 00:14:47 CDT ---
Fixed in r131614.

The override check just has to be delayed until the class is complete, so that
we can generate the spec first.

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

From bugzilla-daemon at llvm.org  Thu May 19 05:00:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 05:00:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9941] Error in simple code in C++0x: exception
 specification of overriding function is more lax than base version
In-Reply-To: <bug-9941-206@http.llvm.org/bugs/>
References: <bug-9941-206@http.llvm.org/bugs/>
Message-ID: <20110519100028.0B26E2A6C124@llvm.org>

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

Christopher Jefferson <chris at bubblescope.net> changed:

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

--- Comment #4 from Christopher Jefferson <chris at bubblescope.net> 2011-05-19 05:00:27 CDT ---
The following simple extension still fails (reopening same bug to avoid lots of
submissions).

struct X
{ virtual ~X() {} };

template<typename T>
struct Y : X
{ virtual ~Y() {} };

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

From bugzilla-daemon at llvm.org  Thu May 19 06:39:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 06:39:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9948] New: dragonegg doesn't compile ImageMagick
Message-ID: <bug-9948-206@http.llvm.org/bugs/>

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

           Summary: dragonegg doesn't compile ImageMagick
           Product: dragonegg
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: dl9pf at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6612)
 --> (http://llvm.org/bugs/attachment.cgi?id=6612)
draw.i 

CC     magick/magick_libMagickCore_la-draw.lo
cc1: /BUILD/llvm/lib/Target/X86/X86FloatingPoint.cpp:1245:
void<unnamed>::FPS::handleSpecialFP(llvm::MachineBasicBlock::iterator&):
Assertion `StackTop == 0 && "Stack should be empty after a call!"' failed.
Stack dump:
0.     Running pass 'X86 FP Stackifier' on function '@DrawPolygonPrimitive'
{standard input}: Assembler messages:
{standard input}:3543: Warning: end of file not at end of a line; newline
inserted
{standard input}:3883: Error: open CFI at the end of file; missing .cfi_endproc
directive
gcc: Internal error: Aborted (program cc1)


Verbose:

/bin/sh ./libtool  --tag=CC   --mode=compile gcc -std=gnu99 -std=gnu99
-DHAVE_CONFIG_H -I. -I./config  -I./ltdl -I./ltdl  -I/usr/include/freetype2
-I/usr/include/libxml2  -fopenmp -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Wformat-security -m32 -march=core2 -mssse3  -mfpmath=sse
-fasynchronous-unwind-tables -fno-omit-frame-pointer
-fplugin=/usr/lib/dragonegg.so -save-temps -v -v -pthread -MT
magick/magick_libMagickCore_la-draw.lo -MD -MP -MF
magick/.deps/magick_libMagickCore_la-draw.Tpo -c -o
magick/magick_libMagickCore_la-draw.lo `test -f 'magick/draw.c' || echo
'./'`magick/draw.c
libtool: compile:  gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -I./config
-I./ltdl -I./ltdl -I/usr/include/freetype2 -I/usr/include/libxml2 -fopenmp -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -m32 -march=core2 -mssse3 
-mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer
-fplugin=/usr/lib/dragonegg.so -save-temps -v -v -pthread -MT
magick/magick_libMagickCore_la-draw.lo -MD -MP -MF
magick/.deps/magick_libMagickCore_la-draw.Tpo -c magick/draw.c 
gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i586-unknown-linux/4.5.2/lto-wrapper
Target: i586-unknown-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking=release --enable-plugin
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-lto
--enable-languages=c,c++,objc,obj-c++,fortran --disable-libgcj
--with-tune=generic --with-arch=i686 --build=i586-unknown-linux
Thread model: posix
gcc version 4.5.2 20101216 (4.5.2-1) [release 4.5-2010.09-1] (GCC) 
COLLECT_GCC_OPTIONS='-std=gnu99' '-std=gnu99' '-DHAVE_CONFIG_H' '-I.'
'-I./config' '-I./ltdl' '-I./ltdl' '-I/usr/include/freetype2'
'-I/usr/include/libxml2' '-fopenmp' '-O2' '-g' '-pipe' '-Wall' '-fexceptions'
'-fstack-protector' '--param' 'ssp-buffer-size=4' '-Wformat'
'-Wformat-security' '-m32' '-march=core2' '-mssse3' '' '-mfpmath=sse'
'-fasynchronous-unwind-tables' '-fno-omit-frame-pointer'
'-fplugin=/usr/lib/dragonegg.so' '-save-temps' '-v' '-v' '-pthread' '-MT'
'magick/magick_libMagickCore_la-draw.lo' '-MD' '-MP' '-MF'
'magick/.deps/magick_libMagickCore_la-draw.Tpo' '-c' '-pthread'
 /usr/libexec/gcc/i586-unknown-linux/4.5.2/cc1 -E -quiet -v -v -I. -I./config
-I./ltdl -I./ltdl -I/usr/include/freetype2 -I/usr/include/libxml2 -MD draw.d
-MF magick/.deps/magick_libMagickCore_la-draw.Tpo -MP -MT
magick/magick_libMagickCore_la-draw.lo -D_REENTRANT -DHAVE_CONFIG_H
-D_FORTIFY_SOURCE=2 magick/draw.c -m32 -march=core2 -mssse3  -mfpmath=sse
-std=gnu99 -std=gnu99 -Wall -Wformat -Wformat-security -fopenmp -fexceptions
-fstack-protector -fasynchronous-unwind-tables -fno-omit-frame-pointer
-fplugin=/usr/lib/dragonegg.so -g -fworking-directory -O2 -fpch-preprocess -o
draw.i
ignoring nonexistent directory
"/usr/lib/gcc/i586-unknown-linux/4.5.2/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/i586-unknown-linux/4.5.2/../../../../i586-unknown-linux/include"
ignoring duplicate directory "./ltdl"
#include "..." search starts here:
#include <...> search starts here:
 .
 ./config
 ./ltdl
 /usr/include/freetype2
 /usr/include/libxml2
 /usr/local/include
 /usr/lib/gcc/i586-unknown-linux/4.5.2/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=gnu99' '-std=gnu99' '-DHAVE_CONFIG_H' '-I.'
'-I./config' '-I./ltdl' '-I./ltdl' '-I/usr/include/freetype2'
'-I/usr/include/libxml2' '-fopenmp' '-O2' '-g' '-pipe' '-Wall' '-fexceptions'
'-fstack-protector' '--param' 'ssp-buffer-size=4' '-Wformat'
'-Wformat-security' '-m32' '-march=core2' '-mssse3' '' '-mfpmath=sse'
'-fasynchronous-unwind-tables' '-fno-omit-frame-pointer'
'-fplugin=/usr/lib/dragonegg.so' '-save-temps' '-v' '-v' '-pthread' '-MT'
'magick/magick_libMagickCore_la-draw.lo' '-MD' '-MP' '-MF'
'magick/.deps/magick_libMagickCore_la-draw.Tpo' '-c' '-pthread'
 /usr/libexec/gcc/i586-unknown-linux/4.5.2/cc1 -fpreprocessed draw.i -quiet
-dumpbase draw.c -m32 -march=core2 -mssse3  -mfpmath=sse -auxbase draw -g -O2
-Wall -Wformat -Wformat-security -std=gnu99 -std=gnu99 -version -fopenmp
-fexceptions -fstack-protector -fasynchronous-unwind-tables
-fno-omit-frame-pointer -fplugin=/usr/lib/dragonegg.so --param
ssp-buffer-size=4 -o draw.s
GNU C (GCC) version 4.5.2 20101216 (4.5.2-1) [release 4.5-2010.09-1]
(i586-unknown-linux)
        compiled by GNU C version 4.5.2 20101216 (4.5.2-1) [release
4.5-2010.09-1], GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Versions of loaded plugins:
 dragonegg: exported
GNU C (GCC) version 4.5.2 20101216 (4.5.2-1) [release 4.5-2010.09-1]
(i586-unknown-linux)
        compiled by GNU C version 4.5.2 20101216 (4.5.2-1) [release
4.5-2010.09-1], GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Versions of loaded plugins:
 dragonegg: exported
Compiler executable checksum: ca26d85630d97f36477bf5201ca83cba
cc1: /BUILD/llvm/lib/Target/X86/X86FloatingPoint.cpp:1245:
void<unnamed>::FPS::handleSpecialFP(llvm::MachineBasicBlock::iterator&):
Assertion `StackTop == 0 && "Stack should be empty after a call!"' failed.
Stack dump:
0.      Running pass 'X86 FP Stackifier' on function '@DrawPolygonPrimitive'
gcc: Internal error: Aborted (program cc1)



draw.i/draw.s attached

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

From bugzilla-daemon at llvm.org  Thu May 19 06:59:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 06:59:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9949] New:
 libatomic_ops/src/atomic_ops/sysdeps/gcc/x86.h:114:3: error: unsupported
 inline asm: input constraint with a matching output constraint of
 incompatible type!
Message-ID: <bug-9949-206@http.llvm.org/bugs/>

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

           Summary: libatomic_ops/src/atomic_ops/sysdeps/gcc/x86.h:114:3:
                    error: unsupported inline asm: input constraint with a
                    matching output constraint of incompatible type!
           Product: dragonegg
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: dl9pf at gmx.de
                CC: llvmbugs at cs.uiuc.edu


While compiling "gc" I see this error:

 gcc -DPACKAGE_NAME=\"gc\" -DPACKAGE_TARNAME=\"gc\" -DPACKAGE_VERSION=\"7.1\"
"-DPACKAGE_STRING=\"gc 7.1\"" -DPACKAGE_BUGREPORT=\"Hans.Boehm at hp.com\"
-DGC_VERSION_MAJOR=7 -DGC_VERSION_MINOR=1 -DPACKAGE=\"gc\" -DVERSION=\"7.1\"
-DGC_LINUX_THREADS=1 -D_REENTRANT=1 -DPARALLEL_MARK=1 -DTHREAD_LOCAL_ALLOC=1
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DNO_EXECUTE_PERMISSION=1
-DALL_INTERIOR_POINTERS=1 -DGC_GCJ_SUPPORT=1 -DJAVA_FINALIZATION=1
-DATOMIC_UNCOLLECTABLE=1 -I./include -fexceptions -I libatomic_ops/src -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Wformat-security -m32 -march=core2 -mssse3
-mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer
-fplugin=/usr/lib/dragonegg.so -c cord/cordtest.c  -fPIC -DPIC -o
cord/.libs/cordtest.o
atomic_ops.c: In function 'lock':
libatomic_ops/src/atomic_ops/sysdeps/gcc/x86.h:114:3: error: unsupported inline
asm: input constraint with a matching output constraint of incompatible type!
libatomic_ops/src/atomic_ops/sysdeps/gcc/x86.h:114:3: error: unsupported inline
asm: input constraint with a matching output constraint of incompatible type!
make[1]: *** [atomic_ops.lo] 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  Thu May 19 07:17:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 07:17:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9948] dragonegg doesn't compile ImageMagick
In-Reply-To: <bug-9948-206@http.llvm.org/bugs/>
References: <bug-9948-206@http.llvm.org/bugs/>
Message-ID: <20110519121719.0892B2A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2011-05-19 07:17:18 CDT ---
Bad interactions between the floating point stack and inline asm are being
tracked in PR2270.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 07:44:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 07:44:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9950] New: regression in trunk...failing make check
Message-ID: <bug-9950-206@http.llvm.org/bugs/>

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

           Summary: regression in trunk...failing make check
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: apacherulzz at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


So I am in the process of narrowing down where this occurred and I am a
software engineer that would loved to get involved in the clang project so I
may be able to come up with a fix or patch.

Story:
I had no problems compiling/testing llvm by itself (check, not check-all) with
gcc 4.1.2 which I understand is not supported. I began to have some issues with
clang so I decided to grab all updates from llvm and clang out of trunk and
recompile. The problem was still there so I grabbed the gcc44/g++44 packages
from CentOS5 yum repo. This is gcc 4.4.4. Still had problems. 4.4.4 _is_
supported so at this point I started going back to find where this regression
occurred.

Results:
Revision#131480 fails ## tests (using GCC 4.1.2/4.4.4)

Revision#131450 passes all (using GCC 4.1.2/4.4.4)

I will try to narrow this down to a specific revision, look at the diffs, and
see whats going on. I suspect that either a bug was not being tested on and
therefore I should not be passing, or that a regression has entered trunk
between 131450 and 131480. As 4.4.4 is supported, I could understand 4.1.2 not
passing tests if a bug was missed but 4.4.4 should be able to pass without
issues.

Hopefully more later today.

apacherulzz

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 11:06:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 11:06:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9951] New: "LLVM ERROR: unsupported relocation of
 variable" from llc as of @131140
Message-ID: <bug-9951-206@http.llvm.org/bugs/>

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

           Summary: "LLVM ERROR: unsupported relocation of variable" from
                    llc as of @131140
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


As of a recent update to dev TOT, I'm seeing this error whenever I try to
generate debugging information with my compiler.  Attached is a test case that
reproduces when run through llc.  (It is possible that I have a bug in how I
generate debugging metadata that is only being exposed by recent changes to
LLVM, but
the debug info I generated previously seemed to generally work correctly.)

I've attached a test case, that if run through llc to generate a native object
file, gives this error:

% llc bugpoint-reduced-simplified.ll  -o a.o -filetype=obj 
LLVM ERROR: unsupported relocation of variable 'Ltmp7'
%

I've searched through recent checkins and it seems that this was introduced by
the changes in 131140:

Author: Rafael Espindola <rafael.espindola at gmail.com>
Date:   Tue May 10 18:39:09 2011 +0000

    Use .cfi_sections to put the unwind info in .debug_frame when possible.
With
    this clang will use .debug_frame in, for example,
    clang -g -c -m32 test.c
    This matches gcc's behaviour. It looks like .debug_frame is a bit bigger
    than .eh_frame, but has the big advantage of not being allocated.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 131140
91177308-0d34-0410-b5e6-96231b3b80d8

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

From bugzilla-daemon at llvm.org  Thu May 19 11:25:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 11:25:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9941] Error in simple code in C++0x: exception
 specification of overriding function is more lax than base version
In-Reply-To: <bug-9941-206@http.llvm.org/bugs/>
References: <bug-9941-206@http.llvm.org/bugs/>
Message-ID: <20110519162541.8740A2A6C124@llvm.org>

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

Sebastian Redl <sebastian.redl at getdesigned.at> changed:

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

--- Comment #5 from Sebastian Redl <sebastian.redl at getdesigned.at> 2011-05-19 11:25:41 CDT ---
And fixed in r131640. Thanks for the report.

I hope we now have all corner cases 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  Thu May 19 11:59:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 11:59:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9952] New: Warn on identical subexpressions to the
 left and right of ||, &&
Message-ID: <bug-9952-206@http.llvm.org/bugs/>

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

           Summary: Warn on identical subexpressions to the left and right
                    of ||, &&
           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


http://www.viva64.com/ru/pvs-studio/ seems to warn on this code:

void f() {
  int a0 = 0, a1 = 1;
  if (a0 == 0 || a0 == 0)
    a1 = 2;
}

It says something along the lines of "There are identical sub-expressions to
the left and to the right of the '||' operator."

Can / should clang do this, too?

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

From bugzilla-daemon at llvm.org  Thu May 19 14:19:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 14:19:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9953] New: Variadic template instantiation with
 apple-blocks causes a codegen error
Message-ID: <bug-9953-206@http.llvm.org/bugs/>

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

           Summary: Variadic template instantiation with apple-blocks
                    causes a codegen error
           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: joshuacweinberg at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6617)
 --> (http://llvm.org/bugs/attachment.cgi?id=6617)
The actual template definitions

I've attached some code files to reproduce this issue.

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

From bugzilla-daemon at llvm.org  Thu May 19 14:56:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 14:56:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9896] 131172 miscompiles CGVTables.cpp
In-Reply-To: <bug-9896-206@http.llvm.org/bugs/>
References: <bug-9896-206@http.llvm.org/bugs/>
Message-ID: <20110519195640.4E4812A6C12E@llvm.org>

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

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

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

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

From bugzilla-daemon at llvm.org  Thu May 19 15:23:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 15:23:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9941] Error in simple code in C++0x: exception
 specification of overriding function is more lax than base version
In-Reply-To: <bug-9941-206@http.llvm.org/bugs/>
References: <bug-9941-206@http.llvm.org/bugs/>
Message-ID: <20110519202356.A8A252A6C124@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #6 from Howard Hinnant <hhinnant at apple.com> 2011-05-19 15:23:56 CDT ---
It looks like we still have a problem when the destructor is defined external
to the class.

Apple clang version 3.0 (trunk 131664) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

In file included from underlying_type.pass.cpp:16:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
/usr/include/c++/v1/__locale:208:18: error: exception specification of
overriding function is more lax than base version
collate<_CharT>::~collate()
                 ^
/usr/include/c++/v1/__locale:100:13: note: overridden virtual function is here
    virtual ~facet();
            ^
In file included from underlying_type.pass.cpp:16:
In file included from /usr/include/c++/v1/iostream:38:
/usr/include/c++/v1/ios:649:29: error: exception specification of overriding
function is more lax than base version
basic_ios<_CharT, _Traits>::~basic_ios()
                            ^
/usr/include/c++/v1/ios:295:13: note: overridden virtual function is here
    virtual ~ios_base();
            ^
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 May 19 15:24:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 15:24:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9954] New: set_terminate doesn't catch exceptions
 thrown by constructors invoked through new
Message-ID: <bug-9954-206@http.llvm.org/bugs/>

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

           Summary: set_terminate doesn't catch exceptions thrown by
                    constructors invoked through new
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: source at sharpsteen.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Simple test case:


#include <iostream>
#include <exception>

class Foo {
public:
  Foo(){
    throw "up";
  }

  ~Foo() {}
};

void crash_handler() {
  std::cout << "Exception thrown!" << std::endl;
  abort();
}

int main(int argc, char **argv){
  std::set_terminate(crash_handler);

  // This gets caught
  //Foo bar = Foo();

  // This doesn't
  Foo *bar = new Foo();

  return 0;
}


Output from GCC:

g++ -o foo exception_test.cpp
./foo

Exception thrown!
Abort trap


Output from Clang:

clang++ -o foo exception_test.cpp
./foo

Abort trap

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

From bugzilla-daemon at llvm.org  Thu May 19 15:33:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 15:33:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9934] Assembler parser gives wrong relocations for
	$foo
In-Reply-To: <bug-9934-206@http.llvm.org/bugs/>
References: <bug-9934-206@http.llvm.org/bugs/>
Message-ID: <20110519203313.0665C2A6C12D@llvm.org>

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

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

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-05-19 15:33:12 CDT ---
Fixed in 131669.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 16:27:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 16:27:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9947] Isel always places memory operands on a root,
 even when there is only one other memory instruction
In-Reply-To: <bug-9947-206@http.llvm.org/bugs/>
References: <bug-9947-206@http.llvm.org/bugs/>
Message-ID: <20110519212725.62D002A6C124@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #9 from Cameron Zwarich <zwarich at apple.com> 2011-05-19 16:27:24 CDT ---
Fixed in r131677.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 16:36:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 16:36:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9601] inline asm with float constant triggers
	assertion
In-Reply-To: <bug-9601-206@http.llvm.org/bugs/>
References: <bug-9601-206@http.llvm.org/bugs/>
Message-ID: <20110519213602.765882A6C124@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #4 from Eric Christopher <echristo at gmail.com> 2011-05-19 16:36:01 CDT ---
Fixed thusly:


[yendi:Data/sources/llvm] echristo% svn ci
Sending        lib/Target/X86/X86ISelLowering.cpp
Adding         test/CodeGen/X86/9601.ll
Transmitting file data ..
Committed revision 131682.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 16:49:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 16:49:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9955] New: MOVLPSmr incorrectly gets LD memory
	operands
Message-ID: <bug-9955-206@http.llvm.org/bugs/>

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

           Summary: MOVLPSmr incorrectly gets LD memory operands
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


I see these failures on CodeGen/X86/swizzle.ll and
CodeGen/X86/vec_shuffle-18.ll. This is a normal store, so it shouldn't be
getting a LD operand.

******************** TEST 'LLVM :: CodeGen/X86/swizzle.ll' FAILED
********************
Script:
--
/Volumes/Data/b/Release+Asserts/bin/llc <
/Volumes/Data/l/test/CodeGen/X86/swizzle.ll -march=x86 -mattr=+sse2 | grep
movlps
/Volumes/Data/b/Release+Asserts/bin/llc <
/Volumes/Data/l/test/CodeGen/X86/swizzle.ll -march=x86 -mattr=+sse2 | grep
movsd
/Volumes/Data/b/Release+Asserts/bin/llc <
/Volumes/Data/l/test/CodeGen/X86/swizzle.ll -march=x86 -mattr=+sse2 |
/Volumes/Data/b/Release+Asserts/bin/not grep movups
--
Exit Code: 1
Command Output (stderr):
--

# Before register coalescing
# Machine code for function swizzle:
Frame Objects:
  fi#-3: size=4, align=8, fixed, at location [SP+12]
  fi#-2: size=4, align=4, fixed, at location [SP+8]
  fi#-1: size=4, align=16, fixed, at location [SP+4]

0L    BB#0: derived from LLVM BB %entry
16L        %vreg0<def> = MOV32rm <fi#-1>, 1, %noreg, 0, %noreg;
mem:LD4[FixedStack-1](align=16) GR32:%vreg0
32L        %vreg1<def> = MOVSDrm %vreg0<kill>, 1, %noreg, 0, %noreg;
mem:LD8[%tmp.i](align=4) FR64:%vreg1 GR32:%vreg0
48L        %vreg2<def> = SUBREG_TO_REG 0, %vreg1<kill>, 5; VR128:%vreg2
FR64:%vreg1
64L        %vreg3<def> = MOV32rm <fi#-2>, 1, %noreg, 0, %noreg;
mem:LD4[FixedStack-2] GR32:%vreg3
80L        MOVLPSmr %vreg3<kill>, 1, %noreg, 0, %noreg, %vreg2<kill>;
mem:ST16[%0](align=4) LD16[%0](align=4) GR32:%vreg3 VR128:%vreg2
96L        RET

# End machine code for function swizzle.

*** Bad machine code: Missing mayLoad flag ***
- function:    swizzle
- basic block: entry 0x7fa4e9833fa0 (BB#0) [0L;112L)
- instruction: 80L    MOVLPSmr %vreg3<kill>, 1, %noreg, 0, %noreg,
%vreg2<kill>; mem:ST16[%0](align=4) LD16[%0](align=4) GR32:%vreg3 VR128:%vreg2
LLVM ERROR: Found 1 machine code errors.
--

The patterns look like this:


def VMOVLPSmr : VPSI<0x13, MRMDestMem, (outs), (ins f64mem:$dst, VR128:$src),
                   "movlps\t{$src, $dst|$dst, $src}",
                   [(store (f64 (vector_extract (bc_v2f64 (v4f32 VR128:$src)),
                                 (iPTR 0))), addr:$dst)]>, VEX;

Maybe it's the (iPTR 0) that is confusing it?

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

From bugzilla-daemon at llvm.org  Thu May 19 16:54:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 16:54:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9953] Variadic template instantiation with
 apple-blocks causes a codegen error
In-Reply-To: <bug-9953-206@http.llvm.org/bugs/>
References: <bug-9953-206@http.llvm.org/bugs/>
Message-ID: <20110519215439.0C80D2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-05-19 16:54:38 CDT ---
This was already fixed in Clang r130930.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 17:47:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 17:47:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9953] Variadic template instantiation with
 apple-blocks causes a codegen error
In-Reply-To: <bug-9953-206@http.llvm.org/bugs/>
References: <bug-9953-206@http.llvm.org/bugs/>
Message-ID: <20110519224721.C25092A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-05-19 17:47:21 CDT ---
If we drop the '...' from this example, we still get a crash. 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  Thu May 19 17:53:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 17:53:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9956] New: Compiling a single file with
 optimizations on takes > 10 minutes
Message-ID: <bug-9956-206@http.llvm.org/bugs/>

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

           Summary: Compiling a single file with optimizations on takes >
                    10 minutes
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: akyrtzi at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ time /usr/bin/clang++ -O3 -c  DiagnosticIDs-1.ii

real    13m17.118s
user    13m14.292s
sys    0m2.795s

gcc for comparison:

$ time /usr/bin/g++ -O3 -c  DiagnosticIDs-1.ii

real    9m12.501s
user    9m10.618s
sys    0m1.867s

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 18:15:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 18:15:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9951] "LLVM ERROR: unsupported relocation of
 variable" from llc as of @131140
In-Reply-To: <bug-9951-206@http.llvm.org/bugs/>
References: <bug-9951-206@http.llvm.org/bugs/>
Message-ID: <20110519231520.CB0242A6C12E@llvm.org>

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

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

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

--- Comment #2 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-05-19 18:15:20 CDT ---
Fixed in 131687.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 18:45:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 18:45:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9955] MOVLPSmr incorrectly gets LD memory operands
In-Reply-To: <bug-9955-206@http.llvm.org/bugs/>
References: <bug-9955-206@http.llvm.org/bugs/>
Message-ID: <20110519234512.ECF002A6C12C@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #2 from Cameron Zwarich <zwarich at apple.com> 2011-05-19 18:45:11 CDT ---
Fixed in r131705.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 18:45:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 18:45:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8810] All tests should pass with the machine code
 verifier added
In-Reply-To: <bug-8810-206@http.llvm.org/bugs/>
References: <bug-8810-206@http.llvm.org/bugs/>
Message-ID: <20110519234527.424432A6C124@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #3 from Cameron Zwarich <zwarich at apple.com> 2011-05-19 18:45:26 CDT ---
This is now fixed as of r131705!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 19:29:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 19:29:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9957] New: cmake -DLLVM_TARGETS_TO_BUILD=PowerPC
	broken
Message-ID: <bug-9957-206@http.llvm.org/bugs/>

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

           Summary: cmake -DLLVM_TARGETS_TO_BUILD=PowerPC broken
           Product: Build scripts
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es


With LLVM-2.9 (release) on powerpc-darwin8:
cmake dies on:

...
-- Performing Test HAVE_BI_ITERATOR
-- Performing Test HAVE_BI_ITERATOR - Failed
-- Performing Test HAVE_STD_ITERATOR
-- Performing Test HAVE_STD_ITERATOR - Success
-- Performing Test HAVE_FWD_ITERATOR
-- Performing Test HAVE_FWD_ITERATOR - Failed
-- Performing Test HAVE_INT64_T
-- Performing Test HAVE_INT64_T - Success
-- Performing Test HAVE_UINT64_T
-- Performing Test HAVE_UINT64_T - Success
-- Performing Test HAVE_U_INT64_T
-- Performing Test HAVE_U_INT64_T - Success
-- Performing Test HAVE_ERROR_T
-- Performing Test HAVE_ERROR_T - Failed
-- Performing Test LLVM_MULTITHREADED
-- Performing Test LLVM_MULTITHREADED - Failed
-- Warning: LLVM will be built thread-unsafe because atomic builtins are
missing
-- Performing Test SUPPORTS_NO_VARIADIC_MACROS_FLAG
-- Performing Test SUPPORTS_NO_VARIADIC_MACROS_FLAG - Success
-- Target triple: powerpc-apple-darwin8.11.0
-- Native target architecture is PowerPC
-- Threads enabled.
-- Performing Test SUPPORTS_FPIC_FLAG
-- Performing Test SUPPORTS_FPIC_FLAG - Success
-- Building with -fPIC
-- Targeting PowerPC
-- Found Perl: /usr/bin/perl 
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - big endian
CMake Error at cmake/modules/LLVMConfig.cmake:127 (message):
  Library `X86' not found in list of llvm libraries.
Call Stack (most recent call first):
  cmake/modules/LLVMConfig.cmake:47 (explicit_map_components_to_libraries)
  cmake/modules/LLVMConfig.cmake:40 (explicit_llvm_config)
  cmake/modules/AddLLVM.cmake:77 (llvm_config)
  cmake/modules/AddLLVM.cmake:96 (add_llvm_executable)
  tools/opt/CMakeLists.txt:3 (add_llvm_tool)


-- Configuring incomplete, errors occurred!


I worked around this by removing the explicit LLVM_TARGETS_TO_BUILD, and
compilation succeeded (all target back-ends enabled).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 19 19:37:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 19:37:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9957] cmake -DLLVM_TARGETS_TO_BUILD=PowerPC broken
In-Reply-To: <bug-9957-206@http.llvm.org/bugs/>
References: <bug-9957-206@http.llvm.org/bugs/>
Message-ID: <20110520003706.125192A6C12E@llvm.org>

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

?scar Fuentes <ofv at wanadoo.es> changed:

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

--- Comment #1 from ?scar Fuentes <ofv at wanadoo.es> 2011-05-19 19:37:05 CDT ---
Fixed on svn time ago.

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

From bugzilla-daemon at llvm.org  Thu May 19 19:44:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 19:44:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9958] New: powerpc-darwin8 build: multiply defined
	_abort
Message-ID: <bug-9958-206@http.llvm.org/bugs/>

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

           Summary: powerpc-darwin8 build: multiply defined _abort
           Product: new-bugs
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu


With LLVM-2.9, building on powerpc-darwin8 (Mac OS X 10.4), compile dies at:

/sw/var/lib/fink/path-prefix-g++-4.0/c++    -fPIC -O3 -DNDEBUG
-mmacosx-version-min=10.4 -Wl,-search_paths_first
-Wl,-headerpad_max_install_names -L/sw/lib
CMakeFiles/tblgen.dir/ARMDecoderEmitter.cpp.o
CMakeFiles/tblgen.dir/AsmMatcherEmitter.cpp.o
CMakeFiles/tblgen.dir/AsmWriterEmitter.cpp.o
CMakeFiles/tblgen.dir/AsmWriterInst.cpp.o
CMakeFiles/tblgen.dir/CallingConvEmitter.cpp.o
CMakeFiles/tblgen.dir/ClangASTNodesEmitter.cpp.o
CMakeFiles/tblgen.dir/ClangAttrEmitter.cpp.o
CMakeFiles/tblgen.dir/ClangDiagnosticsEmitter.cpp.o
CMakeFiles/tblgen.dir/ClangSACheckersEmitter.cpp.o
CMakeFiles/tblgen.dir/CodeEmitterGen.cpp.o
CMakeFiles/tblgen.dir/CodeGenDAGPatterns.cpp.o
CMakeFiles/tblgen.dir/CodeGenInstruction.cpp.o
CMakeFiles/tblgen.dir/CodeGenTarget.cpp.o
CMakeFiles/tblgen.dir/DAGISelEmitter.cpp.o
CMakeFiles/tblgen.dir/DAGISelMatcherEmitter.cpp.o
CMakeFiles/tblgen.dir/DAGISelMatcherGen.cpp.o
CMakeFiles/tblgen.dir/DAGISelMatcherOpt.cpp.o
CMakeFiles/tblgen.dir/DAGISelMatcher.cpp.o
CMakeFiles/tblgen.dir/DisassemblerEmitter.cpp.o
CMakeFiles/tblgen.dir/EDEmitter.cpp.o
CMakeFiles/tblgen.dir/FastISelEmitter.cpp.o
CMakeFiles/tblgen.dir/FixedLenDecoderEmitter.cpp.o
CMakeFiles/tblgen.dir/InstrEnumEmitter.cpp.o
CMakeFiles/tblgen.dir/InstrInfoEmitter.cpp.o
CMakeFiles/tblgen.dir/IntrinsicEmitter.cpp.o
CMakeFiles/tblgen.dir/LLVMCConfigurationEmitter.cpp.o
CMakeFiles/tblgen.dir/NeonEmitter.cpp.o
CMakeFiles/tblgen.dir/OptParserEmitter.cpp.o CMakeFiles/tblgen.dir/Record.cpp.o
CMakeFiles/tblgen.dir/RegisterInfoEmitter.cpp.o
CMakeFiles/tblgen.dir/StringMatcher.cpp.o
CMakeFiles/tblgen.dir/SubtargetEmitter.cpp.o
CMakeFiles/tblgen.dir/TGLexer.cpp.o CMakeFiles/tblgen.dir/TGParser.cpp.o
CMakeFiles/tblgen.dir/TGValueTypes.cpp.o CMakeFiles/tblgen.dir/TableGen.cpp.o
CMakeFiles/tblgen.dir/TableGenBackend.cpp.o
CMakeFiles/tblgen.dir/X86DisassemblerTables.cpp.o
CMakeFiles/tblgen.dir/X86RecognizableInstr.cpp.o  -o ../../bin/tblgen 
-lpthread ../../lib/libLLVMSupport.a -lpthread 
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: multiple definitions of symbol
_abort
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libpthread.dylib(abort.So)
definition of _abort
../../lib/libLLVMSupport.a(Signals.cpp.o) definition of _abort in section
(__TEXT,__text)
collect2: ld returned 1 exit status
make[2]: *** [bin/tblgen] Error 1
make[1]: *** [utils/TableGen/CMakeFiles/tblgen.dir/all] Error 2
make: *** [all] Error 2


cmake options:
CMAKE_OPTIONS="-DLLVM_BUILD_32_BITS:BOOL=ON"
cmake $CMAKE_OPTIONS -DCMAKE_INSTALL_PREFIX=/sw/opt/llvm-2.9
-DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_BUILD_TYPE=Release ..

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

From bugzilla-daemon at llvm.org  Thu May 19 21:34:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 21:34:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9959] New: LLVM test-suite + Apple Externals should
 pass with VerifyCoalescing on x86_64
Message-ID: <bug-9959-206@http.llvm.org/bugs/>

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

           Summary: LLVM test-suite + Apple Externals should pass with
                    VerifyCoalescing on x86_64
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


LLVM test-suite + Apple Externals should pass with VerifyCoalescing on x86_64
at the very least. This is a master bug to track all of the 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  Thu May 19 21:36:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 21:36:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9960] New: VerifyCoalescing failure on Stanford
	QuickSort
Message-ID: <bug-9960-206@http.llvm.org/bugs/>

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

           Summary: VerifyCoalescing failure on Stanford QuickSort
           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: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


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

The coalescer misses a phikill flag on QuickSort. Reduction attached.

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

From bugzilla-daemon at llvm.org  Thu May 19 22:54:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 19 May 2011 22:54:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9960] VerifyCoalescing failure on Stanford QuickSort
In-Reply-To: <bug-9960-206@http.llvm.org/bugs/>
References: <bug-9960-206@http.llvm.org/bugs/>
Message-ID: <20110520035449.2D0F82A6C12D@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #2 from Cameron Zwarich <zwarich at apple.com> 2011-05-19 22:54:48 CDT ---
Fixed in r131717.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 00:36:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 00:36:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9961] New: missing simple store merging
Message-ID: <bug-9961-206@http.llvm.org/bugs/>

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

           Summary: missing simple store merging
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


I wrote the equivalent to this sequence in a function:

  void test(char *ptr) {
    ptr[0] = 0;
    ptr[1] = 0;
  }

and was surprised to see that at -O2, we emit two movb instructions:

        movb    $0, (%rdi)
        movb    $0, 1(%rdi)
        ret

I was really expecting a single movw. Now, gcc 4.5.2 does the exact same thing,
so maybe there's a good reason for this? It sure looks like a missed optz'n to
me.

On x86-32, four ptr[x] = 0 lines will merge into a single movl in llvm but not
in gcc. It doesn't happen in x86-64.

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

From bugzilla-daemon at llvm.org  Fri May 20 00:56:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 00:56:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9962] New: MultiSource/Applications/JM/ldecod fails
 with -verify-coalescing on x86_64
Message-ID: <bug-9962-206@http.llvm.org/bugs/>

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

           Summary: MultiSource/Applications/JM/ldecod fails with
                    -verify-coalescing on x86_64
           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: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


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

block.c from MultiSource/Applications/JM/ldecod fails with -verify-coalescing
on x86_64. I've attached a reduction. This is the failure:

*** Bad machine code: Illegal virtual register for instruction ***
- function:    intrapred_luma_16x16
- basic block: for.end428 0x7fbca9834508 (BB#10) [560L;672L)
- instruction: 576L    %vreg14<def> = LEA64_32r %vreg24<kill>, 4, %vreg24, 32,
%noreg; GR32:%vreg14,%vreg24,%vreg24
- operand 3:   %vreg24
Expected a GR32_NOSP register, but got a GR32 register

It looks like a bug in cross-class coalescing.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 00:58:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 00:58:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9941] Error in simple code in C++0x: exception
 specification of overriding function is more lax than base version
In-Reply-To: <bug-9941-206@http.llvm.org/bugs/>
References: <bug-9941-206@http.llvm.org/bugs/>
Message-ID: <20110520055811.9B1012A6C12D@llvm.org>

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

Sebastian Redl <sebastian.redl at getdesigned.at> changed:

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

--- Comment #7 from Sebastian Redl <sebastian.redl at getdesigned.at> 2011-05-20 00:58:11 CDT ---
Latest incarnation fixed in r131722.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 01:49:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 01:49:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9596] llvm-gcc miscompiles GMP 4.3.2/5.0.1
In-Reply-To: <bug-9596-206@http.llvm.org/bugs/>
References: <bug-9596-206@http.llvm.org/bugs/>
Message-ID: <20110520064916.1A4162A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2011-05-20 01:49:15 CDT ---
This apparently works fine with dragonegg and clang.  Closing since
llvm-gcc is now deprecated.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 02:08:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 02:08:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9963] New: hash in memory and functional collides
Message-ID: <bug-9963-206@http.llvm.org/bugs/>

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

           Summary: hash in memory and functional collides
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: oroppas at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The attached file can be compiled by g++, as g++ -std=c++0x ./hash.cpp
whereas clang++ with libc++ fails to compile it:

$ clang++ -std=c++0x -stdlib=libc++ ./hash.cpp 
./hash.cpp:22:17: error: implicit instantiation of undefined template
      'std::__1::hash<operand::datatype>'
  inline size_t hash<operand::datatype>::operator()(operand::datatype t) const
                ^
/usr/include/c++/v1/memory:2396:25: note: template is declared here
template <class> struct hash;
                        ^
1 error generated.


Cheers,

Ryuta

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 02:26:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 02:26:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9858] targetdata strings starting with "-" causing
 assertion failures
In-Reply-To: <bug-9858-206@http.llvm.org/bugs/>
References: <bug-9858-206@http.llvm.org/bugs/>
Message-ID: <20110520072637.368A32A6C12F@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

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

--- Comment #7 from Nick Lewycky <nicholas at mxc.ca> 2011-05-20 02:26:36 CDT ---
Yes, I've put the buildbots back on gcc 4.4, fixing this bug. I'll have to wait
a bit before upgrading to the newer gcc 4.6 (for it to be packaged), and then I
can switch the buildbots back to 4.6.

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

From bugzilla-daemon at llvm.org  Fri May 20 03:56:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 03:56:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9964] New: ARM Thumb 2: MOV R0, R1 does not work
Message-ID: <bug-9964-206@http.llvm.org/bugs/>

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

           Summary: ARM Thumb 2: MOV R0, R1 does not work
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM assembly language parser
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I have to use MOVS R0, R1.
This would be fine, except I can't use that with immediates.
For inline assembler in Clang this is something of a problem for me. :)
Be nice to be able to use the same instruction for both..

GCC allows asm("mov r0, r1") just fine. Maybe ARM Thumb had
this restriction? ARM Thumb 2 certainly does not.

The error is "error: instruction requires a CPU feature not currently enabled".
Command line is clang -cc1 -emit-obj -target-cpu cortex-m3 -triple
thumb-none-eabi (or thumb-gcc) test.c

clang -cc1 -S of course does not object. It's definitely an assembler problem.

Thanks

James

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

From bugzilla-daemon at llvm.org  Fri May 20 05:11:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 05:11:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9965] New: default constructor not emitted for
	templated class
Message-ID: <bug-9965-206@http.llvm.org/bugs/>

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

           Summary: default constructor not emitted for templated class
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code fails to link, when compiled with -std=gnu++0x. The problem
is that the constructor for X is not emitted.

Removing the template from X, or replacing X's constructor with: X() = {}, or
leaving the default one, fixes the problem.




template<typename T>
struct X
{
  X() = default;
};


int main(void)
{ X<int> l; }

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 05:49:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 05:49:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9949]
 libatomic_ops/src/atomic_ops/sysdeps/gcc/x86.h:114:3: error: unsupported
 inline asm: input constraint with a matching output constraint of
 incompatible type!
In-Reply-To: <bug-9949-206@http.llvm.org/bugs/>
References: <bug-9949-206@http.llvm.org/bugs/>
Message-ID: <20110520104900.EE4DE2A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #4 from Duncan Sands <baldrick at free.fr> 2011-05-20 05:49:00 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110516/121044.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 May 20 08:52:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 08:52:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9966] New: cmake build system doesn't support
 CLANG_VENDOR parameter
Message-ID: <bug-9966-206@http.llvm.org/bugs/>

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

           Summary: cmake build system doesn't support CLANG_VENDOR
                    parameter
           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


With autoconf one can do;

make CLANG_VENDOR="SUSE Linux"

which will make clang -v to say something like:

SUSE Linux clang version 3.0 (trunk 131121) (based on LLVM 3.0svn)

This is a useful way of making sure that users now that this is a modified
version of clang. Would be nice if clang supported it via a define too.

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

From bugzilla-daemon at llvm.org  Fri May 20 09:55:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 09:55:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9963] hash in memory and functional collides
In-Reply-To: <bug-9963-206@http.llvm.org/bugs/>
References: <bug-9963-206@http.llvm.org/bugs/>
Message-ID: <20110520145508.D38262A6C12D@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #2 from Howard Hinnant <hhinnant at apple.com> 2011-05-20 09:55:08 CDT ---
The attached code isn't conforming, and I'm not seeing a motivation to support
it as an extension.  Here is the conforming way to specialize std::hash:

namespace std {
  template<>
  struct hash<operand::datatype>
  {
    std::size_t operator()(operand::datatype t) const
    {
       return (size_t)t;
    }
  };
}

Reference:  [unord.hash]/p1.  There is no definition of the primary template
hash.

Resolving as "not a bug".

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

From bugzilla-daemon at llvm.org  Fri May 20 10:04:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 10:04:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9584] Support __is_standard_layout and
 __is_literal_type for gcc compatibility
In-Reply-To: <bug-9584-206@http.llvm.org/bugs/>
References: <bug-9584-206@http.llvm.org/bugs/>
Message-ID: <20110520150452.8A9F32A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #7 from Douglas Gregor <dgregor at apple.com> 2011-05-20 10:04:51 CDT ---
These type traits are supported in Clang trunk.

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

From bugzilla-daemon at llvm.org  Fri May 20 10:08:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 10:08:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9888] Crash when parsing a piece of template
 metaprogramming code.
In-Reply-To: <bug-9888-206@http.llvm.org/bugs/>
References: <bug-9888-206@http.llvm.org/bugs/>
Message-ID: <20110520150838.4791E2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-05-20 10:08:37 CDT ---
I don't see any benefit to keeping this bug open. Running out of stack space is
an issue, but a particular instance isn't actionable, since Clang isn't doing
anything strange in this particular 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  Fri May 20 10:19:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 10:19:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9967] New: enum class values as default template
 arguments causes segfault in C++0x
Message-ID: <bug-9967-206@http.llvm.org/bugs/>

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

           Summary: enum class values as default template arguments causes
                    segfault in C++0x
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following code segfaults the compiler the the backtrace below. This is
causing problems with boost, because clang claims to support enum structs.

enum struct alignment
{ unaligned };

template <alignment A >
struct X {};

X<alignment::unaligned> x;


Backtrace:

ICE cannot be evaluated!
UNREACHABLE executed at ExprConstant.cpp:3057!
0  clang           0x0000000002649982
1  clang           0x000000000264977e
2  libpthread.so.0 0x00007f3249519c60
3  libc.so.6       0x00007f3248804d05 gsignal + 53
4  libc.so.6       0x00007f3248808ab6 abort + 390
5  clang           0x0000000002634fcf
6  clang           0x00000000019f3d72
clang::Expr::isIntegerConstantExpr(llvm::APSInt&, clang::ASTContext&,
clang::SourceLocation*, bool) const + 204
7  clang           0x00000000016a0c3f
clang::Sema::CheckTemplateArgument(clang::NonTypeTemplateParmDecl*,
clang::QualType, clang::Expr*, clang::TemplateArgument&,
clang::Sema::CheckTemplateArgumentKind) + 689
8  clang           0x000000000169c7de
clang::Sema::CheckTemplateArgument(clang::NamedDecl*,
clang::TemplateArgumentLoc const&, clang::NamedDecl*, clang::SourceLocation,
clang::SourceLocation, unsigned int,
llvm::SmallVectorImpl<clang::TemplateArgument>&,
clang::Sema::CheckTemplateArgumentKind) + 1014
9  clang           0x000000000169d653
clang::Sema::CheckTemplateArgumentList(clang::TemplateDecl*,
clang::SourceLocation, clang::TemplateArgumentListInfo&, bool,
llvm::SmallVectorImpl<clang::TemplateArgument>&) + 1451
10 clang           0x00000000016996b4
clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation,
clang::TemplateArgumentListInfo&) + 520
11 clang           0x000000000169a15d
clang::Sema::ActOnTemplateIdType(clang::CXXScopeSpec&,
clang::OpaquePtr<clang::TemplateName>, clang::SourceLocation,
clang::SourceLocation, clang::ASTTemplateArgsPtr, clang::SourceLocation) + 975
12 clang           0x000000000149c0fb
clang::Parser::AnnotateTemplateIdTokenAsType() + 267
13 clang           0x00000000014b1c5a
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 3874
14 clang           0x00000000014a4e3e
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 88
15 clang           0x00000000014a5251
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 113
16 clang           0x00000000014a4ac6
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2428
17 clang           0x00000000014a40a7
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 283
18 clang           0x000000000148505c clang::ParseAST(clang::Sema&, bool) + 416
19 clang           0x00000000011f119f clang::ASTFrontendAction::ExecuteAction()
+ 263
20 clang           0x0000000001325a7b clang::CodeGenAction::ExecuteAction() +
927
21 clang           0x00000000011f0dfb clang::FrontendAction::Execute() + 325
22 clang           0x00000000011d7feb
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 741
23 clang           0x000000000117ee13
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 909
24 clang           0x000000000117034a cc1_main(char const**, char const**, char
const*, void*) + 952
25 clang           0x000000000117a5a3 main + 496
26 libc.so.6       0x00007f32487efeff __libc_start_main + 255
27 clang           0x000000000116fa19
Stack dump:
0.      Program arguments: /llvmdebug/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.21.51.20110409 -momit-leaf-frame-pointer -resource-dir
/llvmdebug/bin/../lib/clang/3.0 -std=gnu++0x -fdeprecated-macro -ferror-limit
19 -fmessage-length 180 -fcxx-exceptions -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-XS6Ybo.o -x c++ t.cc 
1.      t.cc:8:1: at annotation token 
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  Fri May 20 10:32:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 10:32:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9968] New: False positive "unused variable
 '__range'" with ranged for loop in template
Message-ID: <bug-9968-206@http.llvm.org/bugs/>

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

           Summary: False positive "unused variable '__range'" with ranged
                    for loop in template
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following program results in a warning when compiled with -Wunused:

template <typename T>
struct Vector {
    void doIt()
    {
        for (auto& e : elements)
            (void) e;
    }

    T    elements[10];
};


int main(int, char**)
{
    Vector<int>    vector;
    vector.doIt();
}


This results in:

$ clang -std=c++0x -fsyntax-only -Wunused clang.cpp
clang.cpp:7:18: warning: unused variable '__range' [-Wunused-variable]
                for (auto& e : elements)
                               ^
clang.cpp:18:9: note: in instantiation of member function 'Vector<int>::doIt'
requested here
        vector.doIt();
               ^
1 warning generated.


clang generates correct code for the loop. It is just the warning that is
wrong.

It also only happens if the loop's "__range" variable is dependent on the
template parameter(s).


My clang version:

$ clang --version
clang version 3.0 (trunk 131126)

Target: x86_64-apple-darwin10.7.0
Thread model: posix

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

From bugzilla-daemon at llvm.org  Fri May 20 10:50:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 10:50:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9953] Variadic template instantiation with
 apple-blocks causes a codegen error
In-Reply-To: <bug-9953-206@http.llvm.org/bugs/>
References: <bug-9953-206@http.llvm.org/bugs/>
Message-ID: <20110520155033.E0C492A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-05-20 10:50:33 CDT ---
Fixed the crash in r131731.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 11:00:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 11:00:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9966] cmake build system doesn't support
	CLANG_VENDOR parameter
In-Reply-To: <bug-9966-206@http.llvm.org/bugs/>
References: <bug-9966-206@http.llvm.org/bugs/>
Message-ID: <20110520160008.C24632A6C12D@llvm.org>

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

?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> 2011-05-20 11:00:08 CDT ---
Done in r131733.

For using it:

cmake -DCLANG_VENDOR="SUSE Linux" path/to/llvm/sources

About supporting it as a define, please ask on the 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  Fri May 20 11:08:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 11:08:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9925] Regression: Invalid point of instantiation
 when using std::string from libc++ in C++0x mode
In-Reply-To: <bug-9925-206@http.llvm.org/bugs/>
References: <bug-9925-206@http.llvm.org/bugs/>
Message-ID: <20110520160818.B6AED2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-05-20 11:08:17 CDT ---
This is fixed on trunk.

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

From bugzilla-daemon at llvm.org  Fri May 20 11:36:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 11:36:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9969] New: Warn about missing parameters for ?:
	operator
Message-ID: <bug-9969-206@http.llvm.org/bugs/>

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

           Summary: Warn about missing parameters for ?: operator
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu


http://www.viva64.com/en/d/0091/ seems to warn on this code:

int foo(int a, bool b, int c, int d) { 
  return a + b ? c : d;
}

In this case it's likely that the programmer really meant to write

int foo(int a, bool b, int c, int d) { 
  return a + (b ? c : d);
}

Maybe Clang should warn about this too?

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

From bugzilla-daemon at llvm.org  Fri May 20 11:56:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 11:56:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9970] New: A way to prevent the function-entry-time
 saving of registers
Message-ID: <bug-9970-206@http.llvm.org/bugs/>

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

           Summary: A way to prevent the function-entry-time saving of
                    registers
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I have a function labelled __attribute__((noreturn)), essentially my main(), on
an ARM Thumb 2 where I have 256 bytes of stack. It doesn't generate a return,
but it would be nice if there were an attribute to also disable the
function-entry-time callee-saving of registers for noreturn functions.

Right now I get
   0:   e92d 48f0       stmdb   sp!, {r4, r5, r6, r7, fp, lr}
at the start, which is 24 bytes of stack down the drain, and when I put more
into the function it sometimes ends up 40 bytes.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 14:51:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 14:51:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9910] Constructor mistakenly marked deleted
In-Reply-To: <bug-9910-206@http.llvm.org/bugs/>
References: <bug-9910-206@http.llvm.org/bugs/>
Message-ID: <20110520195132.686E02A6C12C@llvm.org>

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

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

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

--- Comment #4 from Sean Hunt <scshunt at csclub.uwaterloo.ca> 2011-05-20 14:51:31 CDT ---
Tests have been added for this case.

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

From bugzilla-daemon at llvm.org  Fri May 20 15:25:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 15:25:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9971] New: wrong code in union access
Message-ID: <bug-9971-206@http.llvm.org/bugs/>

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

           Summary: wrong code in union access
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mattiase at acm.org
                CC: llvmbugs at cs.uiuc.edu


The test case below (plain C) is miscompiled by clang when using -O2.

clang version 3.0 (trunk 131747)
Target: x86_64-unknown-linux-gnu

typedef union {
    unsigned long long dword[2];
    unsigned short half[8];
} vector_t;

void vrlh(vector_t *va, vector_t *vb, vector_t *vd)
{
    vector_t t;
    for (int i = 0; i < 8; i++) {
        int sh = vb->half[7 - i] & 0xf;
        t.half[7 - i] = va->half[7 - i] << sh | va->half[7 - i] >> (16 - sh);
    }
    vd->dword[1] = t.dword[1];        // These lines will be
    vd->dword[0] = t.dword[0];        // ignored by the compiler.
}

I presume that clang should work like gcc with respects to unions (setting one
member and reading another defined in the punning way).

As you can see, the two last lines seem to have disappeared:

0000000000000000 <vrlh>:
   0:   ba 07 00 00 00          mov    $0x7,%edx
   5:   66 66 2e 0f 1f 84 00    nopw   %cs:0x0(%rax,%rax,1)
   c:   00 00 00 00 
  10:   0f b7 04 57             movzwl (%rdi,%rdx,2),%eax
  14:   44 0f b7 04 56          movzwl (%rsi,%rdx,2),%r8d
  19:   41 83 e0 0f             and    $0xf,%r8d
  1d:   44 88 c1                mov    %r8b,%cl
  20:   41 89 c1                mov    %eax,%r9d
  23:   41 d3 e1                shl    %cl,%r9d
  26:   b9 10 00 00 00          mov    $0x10,%ecx
  2b:   44 29 c1                sub    %r8d,%ecx
  2e:   d3 e8                   shr    %cl,%eax
  30:   44 09 c8                or     %r9d,%eax
  33:   66 89 44 54 f0          mov    %ax,-0x10(%rsp,%rdx,2)
  38:   48 85 d2                test   %rdx,%rdx
  3b:   48 8d 52 ff             lea    -0x1(%rdx),%rdx
  3f:   75 cf                   jne    10 <vrlh+0x10>
  41:   c3                      retq

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

From bugzilla-daemon at llvm.org  Fri May 20 15:37:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 15:37:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9972] New: clang make test...8 unexpected failures
 | CentOS5 GCC4.4.4
Message-ID: <bug-9972-206@http.llvm.org/bugs/>

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

           Summary: clang make test...8 unexpected failures | CentOS5
                    GCC4.4.4
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: apacherulzz at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


compiled in CentOS5 with GCC4.4.4. LLVM builds and checks no problems. Clang
make test gives:

********************
Testing Time: 59.41s
********************
Failing Tests (8):
    Clang :: CodeGen/mmx-builtins.c
    Clang :: CodeGen/mmx-inline-asm.c
    Clang :: CodeGen/vector.c
    Clang :: Headers/c89.c
    Clang :: Headers/stdbool.cpp
    Clang :: Headers/x86-intrinsics-headers.c
    Clang :: Preprocessor/header_lookup1.c
    Clang :: Sema/x86-builtin-palignr.c

  Expected Passes    : 3085
  Expected Failures  : 21
  Unexpected Failures: 8

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 15:56:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 15:56:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9973] New: Assertion getValueKind() == VK_LValue in
 reduced boost testcase
Message-ID: <bug-9973-206@http.llvm.org/bugs/>

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

           Summary: Assertion getValueKind() == VK_LValue in reduced boost
                    testcase
           Product: clang
           Version: unspecified
          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 code below crashes clang, with the backtrace show. While this code is
invalid, it is derived from a boost test case, so it would be nice to fix it.


template<class R, class T> struct dm
{
  typedef R T::*F;
  F f_;
  template<class U> int & call(U u)
  { return u->*f_; }

  template<class U> int operator()(U u)
  { call(u); }
};

template<class R, class T> 
dm<R, T> mem_fn(R T::*) ;

struct test
{ int nullary_v(); };

void f()
{
  test* t;
  mem_fn(&test::nullary_v)(t);
}


t.cc:9:14: warning: control reaches end of non-void function [-Wreturn-type]
  { call(u); }
             ^
t.cc:23:27: note: in instantiation of function template specialization 'dm<int
(), test>::operator()<test *>' requested here                                   
  mem_fn(&test::nullary_v)(t);
                          ^
clang: ExprClassification.cpp:72: Cl
clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const:
Assertion `getValueKind() == VK_LValue' failed.            
0  clang           0x0000000002649982
1  clang           0x000000000264977e
2  libpthread.so.0 0x00007f74c1612c60
3  libc.so.6       0x00007f74c08fdd05 gsignal + 53
4  libc.so.6       0x00007f74c0901ab6 abort + 390
5  libc.so.6       0x00007f74c08f67c5 __assert_fail + 245
6  clang           0x00000000019e651a
clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const +
404
7  clang           0x0000000001378064 clang::Expr::Classify(clang::ASTContext&)
const + 40
8  clang           0x0000000001637bbc
9  clang           0x000000000163992a
clang::InitializationSequence::InitializationSequence(clang::Sema&,
clang::InitializedEntity const&, clang::InitializationKind const&,
clang::Expr**, unsigned int) + 694
10 clang           0x000000000163f558
clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&,
clang::SourceLocation, clang::ActionResult<clang::Expr*, true>) + 282
11 clang           0x00000000016870d1
clang::Sema::PerformMoveOrCopyInitialization(clang::InitializedEntity const&,
clang::VarDecl const*, clang::QualType, clang::Expr*) + 891
12 clang           0x0000000001687cf2
clang::Sema::ActOnReturnStmt(clang::SourceLocation, clang::Expr*) + 1748
13 clang           0x00000000017413d8
14 clang           0x0000000001734ba8
15 clang           0x000000000172b404
16 clang           0x0000000001740e20
17 clang           0x0000000001733068
18 clang           0x000000000172b154
19 clang           0x0000000001727b4d clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 121
20 clang           0x0000000001754b8d
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2033
21 clang           0x0000000001756f38
clang::Sema::PerformPendingInstantiations(bool) + 334
22 clang           0x0000000001754cb0
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2324
23 clang           0x0000000001756f38
clang::Sema::PerformPendingInstantiations(bool) + 334
24 clang           0x00000000014e442f clang::Sema::ActOnEndOfTranslationUnit()
+ 381
25 clang           0x00000000014a403e
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 178
26 clang           0x000000000148505c clang::ParseAST(clang::Sema&, bool) + 416
27 clang           0x00000000011f119f clang::ASTFrontendAction::ExecuteAction()
+ 263
28 clang           0x0000000001325a7b clang::CodeGenAction::ExecuteAction() +
927
29 clang           0x00000000011f0dfb clang::FrontendAction::Execute() + 325
30 clang           0x00000000011d7feb
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 741
31 clang           0x000000000117ee13
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 909
32 clang           0x000000000117034a cc1_main(char const**, char const**, char
const*, void*) + 952
33 clang           0x000000000117a5a3 main + 496
34 libc.so.6       0x00007f74c08e8eff __libc_start_main + 255
35 clang           0x000000000116fa19
Stack dump:
0.      Program arguments: /llvmdebug/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.21.51.20110409 -momit-leaf-frame-pointer -coverage-file t.o -resource-dir
/llvmdebug/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 173 -fcxx-exceptions -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 
1.      <eof> parser at end of file
2.      t.cc:8:25: instantiating function definition 'operator()'
3.      t.cc:5:27: instantiating function definition 'call'
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  Fri May 20 16:10:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 16:10:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9974] New: Assertion "Assertion `Arg !=
 S.Context.OverloadTy && "Unresolved overloaded function"' failed.
Message-ID: <bug-9974-206@http.llvm.org/bugs/>

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

           Summary: Assertion "Assertion `Arg != S.Context.OverloadTy &&
                    "Unresolved overloaded function"' failed.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The invalid C++0x code (the rvalue reference is required), derived from a boost
test case, causes clang to assert.

template <int> struct enable_if;
template <class > struct remove_reference ;
template <class _Tp> struct remove_reference<_Tp&> ;

template <class > struct __tuple_like;

template <class _Tp, class _Up, int = __tuple_like<typename
remove_reference<_Tp>::type>::value> 
struct __tuple_convertible;

struct pair
{
template<class _Tuple, int = enable_if<__tuple_convertible<_Tuple,
pair>::value>::type> 
pair(_Tuple&& );
};

template <class> struct basic_ostream;

template <int> 
void endl( ) ;

extern basic_ostream<char> cout;

int operator<<( basic_ostream<char> , pair ) ;

void register_object_imp ( )
{
cout << endl<1>;
}




aj at nyanko:/dev/shm/clang-3$ /llvmdebug/bin/clang++ t.cc -c
t.cc:13:12: warning: rvalue references are a C++0x extension
[-Wc++0x-extensions]
pair(_Tuple&& );
           ^
t.cc:12:28: warning: default template arguments for a function template are a
C++0x extension [-Wc++0x-extensions]                                            
template<class _Tuple, int = enable_if<__tuple_convertible<_Tuple,
pair>::value>::type> 
                           ^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
clang: SemaTemplateDeduction.cpp:1001: clang::Sema::TemplateDeductionResult
DeduceTemplateArguments(clang::Sema&, clang::TemplateParameterList*,
clang::QualType, clang::QualType, clang::sema::TemplateDeductionInfo&,
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>&, unsigned int, bool,
llvm::SmallVectorImpl<RefParamPartialOrderingComparison>*): Assertion `Arg !=
S.Context.OverloadTy && "Unresolved overloaded function"' failed.
0  clang           0x0000000002649982
1  clang           0x000000000264977e
2  libpthread.so.0 0x00007f9bc32c2c60
3  libc.so.6       0x00007f9bc25add05 gsignal + 53
4  libc.so.6       0x00007f9bc25b1ab6 abort + 390
5  libc.so.6       0x00007f9bc25a67c5 __assert_fail + 245
6  clang           0x00000000016f2ce6
7  clang           0x00000000016f32ac
8  clang           0x00000000016f4212
9  clang           0x00000000016f4afe
10 clang           0x00000000016f5285
11 clang           0x00000000016f67c4
clang::Sema::DeduceTemplateArguments(clang::ClassTemplatePartialSpecializationDecl*,
clang::TemplateArgumentList const&, clang::sema::TemplateDeductionInfo&) + 210
12 clang           0x0000000001726e38
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 546
13 clang           0x000000000178344d
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&, std::pair<clang::SourceLocation,
clang::PartialDiagnostic>) + 315
14 clang           0x0000000001783823
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&) + 111
15 clang           0x00000000014fe1a3
clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&,
clang::DeclContext*) + 353
16 clang           0x00000000016ab04c
clang::Sema::CheckTypenameType(clang::ElaboratedTypeKeyword,
clang::SourceLocation, clang::NestedNameSpecifierLoc, clang::IdentifierInfo
const&, clang::SourceLocation) + 320
17 clang           0x000000000173ff1e
18 clang           0x000000000173160f
19 clang           0x000000000172a007
20 clang           0x0000000001729886
21 clang           0x00000000017453a4
22 clang           0x0000000001746b2f
23 clang           0x000000000173fa64
24 clang           0x000000000173e3cd
25 clang           0x000000000172ce18
26 clang           0x000000000173a280
27 clang           0x000000000172bd83
28 clang           0x0000000001727bc9 clang::Sema::SubstExpr(clang::Expr*,
clang::MultiLevelTemplateArgumentList const&) + 121
29 clang           0x000000000169bd74
30 clang           0x000000000169d8f5
clang::Sema::CheckTemplateArgumentList(clang::TemplateDecl*,
clang::SourceLocation, clang::TemplateArgumentListInfo&, bool,
llvm::SmallVectorImpl<clang::TemplateArgument>&) + 2125
31 clang           0x00000000016996b4
clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation,
clang::TemplateArgumentListInfo&) + 520
32 clang           0x0000000001746c31
33 clang           0x000000000173fab8
34 clang           0x000000000173e3cd
35 clang           0x000000000172ce18
36 clang           0x000000000173a280
37 clang           0x000000000172bd83
38 clang           0x000000000174595e
39 clang           0x0000000001746b2f
40 clang           0x000000000173fa64
41 clang           0x000000000173e3cd
42 clang           0x000000000172ce18
43 clang           0x000000000173a280
44 clang           0x000000000172bd83
45 clang           0x0000000001727bc9 clang::Sema::SubstExpr(clang::Expr*,
clang::MultiLevelTemplateArgumentList const&) + 121
46 clang           0x000000000169bd74
47 clang           0x000000000169c1c4
clang::Sema::SubstDefaultTemplateArgumentIfAvailable(clang::TemplateDecl*,
clang::SourceLocation, clang::SourceLocation, clang::Decl*,
llvm::SmallVectorImpl<clang::TemplateArgument>&) + 468
48 clang           0x00000000016f7813
clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*,
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>&, unsigned int,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 1549
49 clang           0x00000000016f9196
clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*,
clang::TemplateArgumentListInfo*, clang::Expr**, unsigned int,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 2690
50 clang           0x0000000001668111
clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*,
clang::DeclAccessPair, clang::TemplateArgumentListInfo*, clang::Expr**,
unsigned int, clang::OverloadCandidateSet&, bool) + 243
51 clang           0x0000000001661546
52 clang           0x000000000165c246
53 clang           0x0000000001665194
54 clang           0x000000000166717a
clang::Sema::AddOverloadCandidate(clang::FunctionDecl*, clang::DeclAccessPair,
clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool, bool) + 1334
55 clang           0x0000000001667476
clang::Sema::AddFunctionCandidates(clang::UnresolvedSetImpl const&,
clang::Expr**, unsigned int, clang::OverloadCandidateSet&, bool) + 520
56 clang           0x0000000001674c54
clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int,
clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*) + 1636
57 clang           0x00000000015e3540 clang::Sema::BuildBinOp(clang::Scope*,
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) +
498
58 clang           0x00000000015e334c clang::Sema::ActOnBinOp(clang::Scope*,
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 184
59 clang           0x00000000014c7268
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*,
true>, clang::prec::Level) + 2132
60 clang           0x00000000014c691d
clang::Parser::ParseAssignmentExpression() + 207
61 clang           0x00000000014c66ee clang::Parser::ParseExpression() + 24
62 clang           0x0000000001492923
clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 77
63 clang           0x00000000014924e5
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 2221
64 clang           0x00000000014943b9
clang::Parser::ParseCompoundStatementBody(bool) + 1103
65 clang           0x0000000001497f3e
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 240
66 clang           0x00000000014a5d74
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 2820
67 clang           0x00000000014af55b
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 521
68 clang           0x00000000014a51d5
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 1007
69 clang           0x00000000014a5251
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 113
70 clang           0x00000000014a4ac6
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2428
71 clang           0x00000000014a40a7
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 283
72 clang           0x000000000148505c clang::ParseAST(clang::Sema&, bool) + 416
73 clang           0x00000000011f119f clang::ASTFrontendAction::ExecuteAction()
+ 263
74 clang           0x0000000001325a7b clang::CodeGenAction::ExecuteAction() +
927
75 clang           0x00000000011f0dfb clang::FrontendAction::Execute() + 325
76 clang           0x00000000011d7feb
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 741
77 clang           0x000000000117ee13
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 909
78 clang           0x000000000117034a cc1_main(char const**, char const**, char
const*, void*) + 952
79 clang           0x000000000117a5a3 main + 496
80 libc.so.6       0x00007f9bc2598eff __libc_start_main + 255
81 clang           0x000000000116fa19
Stack dump:
0.      Program arguments: /llvmdebug/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
t.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.21.51.20110409 -momit-leaf-frame-pointer -coverage-file t.o -resource-dir
/llvmdebug/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 173 -fcxx-exceptions -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o t.o -x c++ t.cc 
1.      t.cc:27:16: current parser token ';'
2.      t.cc:26:1: parsing function body 'register_object_imp'
3.      t.cc:26:1: 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  Fri May 20 16:29:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 16:29:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9975] New: [C++0x] Inconsistency I don't understand
Message-ID: <bug-9975-206@http.llvm.org/bugs/>

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

           Summary: [C++0x] Inconsistency I don't understand
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6623)
 --> (http://llvm.org/bugs/attachment.cgi?id=6623)
Does not compile

I have two programs involving clang tip-of-trunk in c++0x mode which I can not
reconcile.  The version is:

Apple clang version 3.0 (trunk 131724) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

The attached preprocessed test1.cpp does not compile and the first error
message is:

$ clang++ -std=c++0x test1.cpp

In file included from test.cpp:1:
In file included from test.cpp:16:
/usr/include/c++/v1/functional:1620:8: error: no type named 'type' in
'std::__1::__invoke_of<void (*&)(const std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> > &), char const
(&)[1]>'
    >::type type;
    ~~~^~~~
/usr/include/c++/v1/functional:1670:18: note: in instantiation of template
class 'std::__1::__bind_return<void (*)(const std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> > &),
std::__1::tuple<std::__1::placeholders::__ph<1> >, std::__1::tuple<char const
(&)[1]> >'
      requested here
        typename __bind_return<_Fd, _Td, tuple<_Args&&...> >::type
                 ^
/usr/include/c++/v1/functional:1671:9: note: while substituting deduced
template arguments into function template 'operator()'
      [with _Args = <char const (&)[1]>]
        operator()(_Args&& ...__args)
        ^
test.cpp:31:3: note: in instantiation of function template specialization
'doIt<std::__1::__bind<void (*)(const std::__1::basic_string<char,
      std::__1::char_traits<char>, std::__1::allocator<char> > &),
std::__1::placeholders::__ph<1> &> >' requested here
  doIt(std::bind(&method, _1));
  ^

In investigating the cause of this error message I developed test2.cpp which
compiles, runs and outputs:

$ clang++ -std=c++0x -stdlib=libc++ test2.cpp
1
v

This second test is directly inspecting the trait std::__invoke_of mentioned in
test1's error message:

std::cout << typeid(std::__invoke_of<void (*&)(const std::string &), char const
(&)[1]>::type).name() << '\n';

Its output contradicts the error message from test1, indicating that this
invocation of std::__invoke *does* have a nested type named 'type', and it has
type 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  Fri May 20 17:21:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 17:21:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9923] enum class streaming causes clang stack dump
In-Reply-To: <bug-9923-206@http.llvm.org/bugs/>
References: <bug-9923-206@http.llvm.org/bugs/>
Message-ID: <20110520222153.9E1412A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-05-20 17:21:52 CDT ---
Fixed in Clang rr131735.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 17:22:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 17:22:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9976] New: Crash in
 LiveVariables::runOnMachineFunction in Release builds
Message-ID: <bug-9976-206@http.llvm.org/bugs/>

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

           Summary: Crash in LiveVariables::runOnMachineFunction in
                    Release builds
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sean at caustic.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6625)
 --> (http://llvm.org/bugs/attachment.cgi?id=6625)
Patch with test case and fix

I see a crash in LiveVariables::runOnMachineFunction where it transfers the
dead/kill information to machine instructions. The loop accesses memory past
the end of an array.

This crash occurs only on Windows and only with Release/RelWithDebInfo builds.
It does not occur in Debug builds, nor on Mac OS X or Linux.

I have attached a fix (w/ test case). I modified the loop to work like other
similar iterations in the LiveVariables class, and to use the "getVarInfo()"
method, which will grow the array in question as necessary, preventing the
out-of-bounds access.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 18:21:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 18:21:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9967] enum class values as default template
 arguments causes segfault in C++0x
In-Reply-To: <bug-9967-206@http.llvm.org/bugs/>
References: <bug-9967-206@http.llvm.org/bugs/>
Message-ID: <20110520232107.99F072A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-05-20 18:21:07 CDT ---
This was fixed in Clang r131735.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 18:27:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 18:27:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9962] MultiSource/Applications/JM/ldecod fails with
 -verify-coalescing on x86_64
In-Reply-To: <bug-9962-206@http.llvm.org/bugs/>
References: <bug-9962-206@http.llvm.org/bugs/>
Message-ID: <20110520232716.AD8162A6C124@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

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

From bugzilla-daemon at llvm.org  Fri May 20 18:40:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 18:40:28 -0500 (CDT)
Subject: [LLVMbugs] =?utf-8?q?=5BBug_9977=5D_New=3A_clang_should_warn_on_m?=
 =?utf-8?b?ZW1zZXQocywgMCwgc2l6ZW9mKHMpKSAg4oCTIG5lZWRzIHRvIGJlIHNpemVv?=
 =?utf-8?b?ZiAoKnMp?=
Message-ID: <bug-9977-206@http.llvm.org/bugs/>

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

           Summary: clang should warn on memset(s, 0, sizeof(s)) ? needs
                    to be sizeof(*s)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


#include <memory.h>

struct S {
  char a;
};

void f(S* s) {
  memset(s, 0, sizeof(s));
}


clang should warn that the memset call is missing a dereference for s. This is
a common error and easy to catch.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 18:57:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 18:57:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9978] New: VerifyCoalescing failure on
 MultiSource/Benchmarks/btAlignedAllocator.cpp on x86_64
Message-ID: <bug-9978-206@http.llvm.org/bugs/>

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

           Summary: VerifyCoalescing failure on
                    MultiSource/Benchmarks/btAlignedAllocator.cpp on
                    x86_64
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


Here is a reduction of the failure:

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-macosx10.7.0"

@_ZL9sFreeFunc = internal unnamed_addr global void ()* @_ZL13btFreeDefaultPv,
align 8

define internal void @_ZL13btFreeDefaultPv() nounwind ssp {
entry:
  ret void
}

define void @_Z21btAlignedFreeInternalPv() ssp {
entry:
  %tmp8 = load void ()** @_ZL9sFreeFunc, align 8
  tail call void %tmp8()
  ret void
}

# Before register coalescing
# Machine code for function _Z21btAlignedFreeInternalPv:

0L    BB#0: derived from LLVM BB %entry
16L        TCRETURNmi64 %RIP, 1, %noreg, <ga:@_ZL9sFreeFunc>, %noreg, 0,
%RSP<imp-use>, ...; mem:LD8[@_ZL9sFreeFunc]

# End machine code for function _Z21btAlignedFreeInternalPv.

*** Bad machine code: Illegal physical register for instruction ***
- function:    _Z21btAlignedFreeInternalPv
- basic block: entry 0x7fdf1202ffa0 (BB#0) [0L;32L)
- instruction: 16L    TCRETURNmi64 %RIP, 1, %noreg, <ga:@_ZL9sFreeFunc>,
%noreg, 0, %RSP<imp-use>, ...; mem:LD8[@_ZL9sFreeFunc]
- operand 0:   %RIP
RIP is not a GR64_TC register.
LLVM ERROR: Found 1 machine code 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  Fri May 20 20:05:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 20:05:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9971] wrong code in union access
In-Reply-To: <bug-9971-206@http.llvm.org/bugs/>
References: <bug-9971-206@http.llvm.org/bugs/>
Message-ID: <20110521010526.8BFD12A6C12D@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #2 from Dan Gohman <gohman at apple.com> 2011-05-20 20:05:26 CDT ---
Fixed in r131781.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 23:14:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 23:14:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9978] VerifyCoalescing failure on
 MultiSource/Benchmarks/btAlignedAllocator.cpp on x86_64
In-Reply-To: <bug-9978-206@http.llvm.org/bugs/>
References: <bug-9978-206@http.llvm.org/bugs/>
Message-ID: <20110521041410.C33512A6C124@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #3 from Cameron Zwarich <zwarich at apple.com> 2011-05-20 23:14:10 CDT ---
Fixed in r131787.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 20 23:24:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 20 May 2011 23:24:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9979] New: VerifyCoalescing failure on
 MultiSource/Benchmarks/btSoftBody.cpp on x86_64
Message-ID: <bug-9979-206@http.llvm.org/bugs/>

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

           Summary: VerifyCoalescing failure on
                    MultiSource/Benchmarks/btSoftBody.cpp on x86_64
           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: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


I've attached a reduction. Here's the error:

*** Bad machine code: Value live out of predecessor doesn't have PHIKill ***
- function:    _ZN15btSoftColliders12CollideVF_SS7ProcessEPK10btDbvtNodeS3_
Valno #2 live out of BB#1 at 192S doesn't have PHIKill, but Valno #1 is PHIDef and
defined at the beginning of BB#3 at 272L in %vreg20 =
[96d,240d:2)[240d,272L:0)[272L,464d:1)[464d,496d:3)  0 at 240d-phikill
1 at 272L-phidef 2 at 96d 3 at 464d
LLVM ERROR: Found 1 machine code errors.

All of the remaining verifier failures on the non-External test-suite are due
to missing phikill flags, so I suspect they are all instances of this same 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  Sat May 21 02:32:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 02:32:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9980] New: Multiple __COUNTER__s
Message-ID: <bug-9980-206@http.llvm.org/bugs/>

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

           Summary: Multiple __COUNTER__s
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


It would be nice if it were possible to have multiple __COUNTER__s, for example
if __COUNTER__uniquename__ would be a new counter starting at 0.

This idea came to me after looking at
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html and realizing that
in Clang, instead of __LINE__ for their unique ID, __COUNTER__ would work great
and be far more space efficient (well, after bit shifting it right, as it has
to be used twice...).

However, if one were to use counter to generate unique IDs for macros for
branching like talked about on that site, any other use of the counter could
foul up the endeavor (the starting state being zero). For example, since
__COUNTER__ increments every use, their crReturn requiring two increments, to
use the same ID you have to do the macro as (__COUNTER__ >> 1). However, if
someone used __COUNTER__ once outside of macros defined for these poor-man's
coroutines, the second might end up as a separate number (0, 1 becoming 1, 2,
etc.).

Anyway, it's not very important, but if it's easy give it some consideration.
:)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 02:45:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 02:45:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9980] Multiple __COUNTER__s
In-Reply-To: <bug-9980-206@http.llvm.org/bugs/>
References: <bug-9980-206@http.llvm.org/bugs/>
Message-ID: <20110521074514.5C7032A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-21 02:45:13 CDT ---
Sorry, this could be useful, but it is so marginal it isn't worth the
implementation, documentation, support costs etc.

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

From bugzilla-daemon at llvm.org  Sat May 21 05:09:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 05:09:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9981] New: crash with ## token
Message-ID: <bug-9981-206@http.llvm.org/bugs/>

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

           Summary: crash with ## token
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jens.gustedt at loria.fr
                CC: llvmbugs at cs.uiuc.edu


The following code can be used to crash clang for me.
The issue is that the ## token is a valid preprocessing token, even
outside macro declarations. We should be able to use it whenever other
treatment ensures that it doesn't land as such in the preprocessed C code.

Admittedly this is just a bizarre corner case, but still...
It is one of the points why clang is not completely C99 conforming, see
http://p99.gforge.inria.fr/c99-conformance/c99-conformance-clang-2.9.html

Jens

#define STRINGIFY_(A) #A
#define STRINGIFY(A) STRINGIFY_(A)
#define DONT_CONCAT_(X) A X B
#define DONT_CONCAT(X) DONT_CONCAT_(X)
char const has_hash_hash_as_argument[] = STRINGIFY(DONT_CONCAT(##));

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 13:56:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 13:56:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8700] clang++ accepts storage class on explicit
 template specialization
In-Reply-To: <bug-8700-206@http.llvm.org/bugs/>
References: <bug-8700-206@http.llvm.org/bugs/>
Message-ID: <20110521185625.001DA2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-05-21 13:56:24 CDT ---
Fixed in Clang r131802.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 14:24:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 14:24:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7952] dyn_cast<> on multi-level pointers causes
	errors
In-Reply-To: <bug-7952-206@http.llvm.org/bugs/>
References: <bug-7952-206@http.llvm.org/bugs/>
Message-ID: <20110521192441.565B82A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #4 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-21 14:24:40 CDT ---
r131803/r131804.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 16:05:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 16:05:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9973] Assertion getValueKind() == VK_LValue in
 reduced boost testcase
In-Reply-To: <bug-9973-206@http.llvm.org/bugs/>
References: <bug-9973-206@http.llvm.org/bugs/>
Message-ID: <20110521210520.1D8AD2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-05-21 16:05:19 CDT ---
Fixed in Clang r131810.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 16:54:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 16:54:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9975] [C++0x] Inconsistency I don't understand
In-Reply-To: <bug-9975-206@http.llvm.org/bugs/>
References: <bug-9975-206@http.llvm.org/bugs/>
Message-ID: <20110521215418.617F42A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-05-21 16:54:17 CDT ---
Closing as invalid. Thanks Richard!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 17:17:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 17:17:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9974] Assertion "Assertion `Arg !=
 S.Context.OverloadTy && "Unresolved overloaded function"' failed.
In-Reply-To: <bug-9974-206@http.llvm.org/bugs/>
References: <bug-9974-206@http.llvm.org/bugs/>
Message-ID: <20110521221713.EE0302A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-05-21 17:17:13 CDT ---
Fixed in Clang r131811.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 21 18:25:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 21 May 2011 18:25:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9982] New: Templated function returning an
 apple-block throwing assertion
Message-ID: <bug-9982-206@http.llvm.org/bugs/>

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

           Summary: Templated function returning an apple-block throwing
                    assertion
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joshuacweinberg at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6626)
 --> (http://llvm.org/bugs/attachment.cgi?id=6626)
Code that fires the assertion

Compiling the attached code throws an assertion when compiling

Assertion failed: (Stored.get<Decl *>() == Inst && "Already instantiated this
local"), function InstantiatedLocal, file
/Users/jweinberg/Development/llvm/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp,
line 2268.
0  clang             0x00000001107d48e2 _ZL15PrintStackTracePv + 34
1  clang             0x00000001107d4ee9 _ZL13SignalHandleri + 745
2  libsystem_c.dylib 0x00007fff8ee61d3a _sigtramp + 26
3  clang             0x000000010fd0c7f1 clang::DeclRefExpr::computeDependence()
+ 245
4  clang             0x00000001107d4846 abort + 22
5  clang             0x00000001107d4898 __assert_rtn + 56
6  clang             0x000000010fb24f58
clang::LocalInstantiationScope::InstantiatedLocal(clang::Decl const*,
clang::Decl*) + 120
7  clang             0x000000010fb2885f
clang::Sema::SubstParmVarDecl(clang::ParmVarDecl*,
clang::MultiLevelTemplateArgumentList const&, int, llvm::Optional<unsigned
int>) + 717
8  clang             0x000000010fb29331 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformFunctionTypeParams(clang::SourceLocation,
clang::ParmVarDecl**, unsigned int, clang::QualType const*,
llvm::SmallVectorImpl<clang::QualType>&,
llvm::SmallVectorImpl<clang::ParmVarDecl*>*) + 1615
9  clang             0x000000010fb2bf74 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 2372
10 clang             0x000000010fb3358c clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 32604
11 clang             0x000000010fb38d93 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc) + 4769
12 clang             0x000000010fb3ba7e clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) + 254
13 clang             0x000000010fb2f6ba clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 16522
14 clang             0x000000010fb3358c clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 32604
15 clang             0x000000010fb2b081 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 5869
16 clang             0x000000010fb4341f clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 137
17 clang             0x000000010fb2a41a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2694
18 clang             0x000000010fb2c1fa clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 3018
19 clang             0x000000010fb3358c clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 32604
20 clang             0x000000010fb38d93 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc) + 4769
21 clang             0x000000010fb3ba7e clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) + 254
22 clang             0x000000010fb2f6ba clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 16522
23 clang             0x000000010fb3358c clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) + 32604
24 clang             0x000000010fb2b081 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 5869
25 clang             0x000000010fb4341f clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 137
26 clang             0x000000010fb2a41a clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2694
27 clang             0x000000010fb4358a clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 60
28 clang             0x000000010fb52f14
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2478
29 clang             0x000000010fb52415
clang::Sema::PerformPendingInstantiations(bool) + 631
30 clang             0x000000010f93326c
clang::Sema::ActOnEndOfTranslationUnit() + 314
31 clang             0x000000010f91b859
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 103
32 clang             0x000000010f8dca5d clang::ParseAST(clang::Sema&, bool) +
317
33 clang             0x000000010f8bb8ec clang::CodeGenAction::ExecuteAction() +
874
34 clang             0x000000010f6f7b21
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 947
35 clang             0x000000010f6d2e87
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1863
36 clang             0x000000010f6cd31b cc1_main(char const**, char const**,
char const*, void*) + 2779
37 clang             0x000000010f6cfe70 main + 640
38 clang             0x000000010f6cc834 start + 52
Stack dump:
0.    Program arguments:
/Users/jweinberg/Development/llvm/build/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free -main-file-name
main.mm -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 123.2.1 -g -coverage-file
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Intermediates/LLVMCrash.build/Debug/LLVMCrash.build/Objects-normal/x86_64/main.o
-resource-dir
/Users/jweinberg/Development/llvm/build/Release+Asserts/bin/../lib/clang/3.0
-isysroot /Developer/SDKs/MacOSX10.7.sdk -iquote
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Intermediates/LLVMCrash.build/Debug/LLVMCrash.build/LLVMCrash-generated-files.hmap
-iquote
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Intermediates/LLVMCrash.build/Debug/LLVMCrash.build/LLVMCrash-project-headers.hmap
-include-pch
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/PrecompiledHeaders/LLVMCrash-Prefix-fzespubklratzmhatcxbelzfnyvm/LLVMCrash-Prefix.pch.pth
-D DEBUG=1 -D IBOutlet=__attribute__((iboutlet)) -D
IBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName))) -D
IBAction=void)__attribute__((ibaction) -I
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Intermediates/LLVMCrash.build/Debug/LLVMCrash.build/LLVMCrash-own-target-headers.hmap
-I
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Intermediates/LLVMCrash.build/Debug/LLVMCrash.build/LLVMCrash-all-target-headers.hmap
-I
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Products/Debug/include
-I
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Intermediates/LLVMCrash.build/Debug/LLVMCrash.build/DerivedSources/x86_64
-I
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Intermediates/LLVMCrash.build/Debug/LLVMCrash.build/DerivedSources
-F/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Products/Debug
-O0 -Wno-trigraphs -Wmissing-prototypes -Wreturn-type -Wparentheses -Wswitch
-Wno-unused-parameter -Wunused-variable -Wunused-value -Wshorten-64-to-32
-std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 0
-fvisibility-inlines-hidden -fdiagnostics-print-source-range-info
-fdiagnostics-parseable-fixits -stack-protector 1 -fblocks -fobjc-exceptions
-fexceptions -fobjc-nonfragile-abi -fobjc-dispatch-method=mixed
-fpascal-strings -fdiagnostics-show-option -fdiagnostics-show-category id -o
/Users/jweinberg/Library/Developer/Xcode/DerivedData/LLVMCrash-aoaiwztifpaxtjbplatutgennbqh/Build/Intermediates/LLVMCrash.build/Debug/LLVMCrash.build/Objects-normal/x86_64/main.o
-x objective-c++ /Users/jweinberg/Development/LLVMCrash/LLVMCrash/main.mm 
1.    <eof> parser at end of file
2.    /Users/jweinberg/Development/LLVMCrash/LLVMCrash/Curry.h:47:11:
instantiating function definition 'operator()'
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)
Command /Users/jweinberg/Development/llvm/build/Release+Asserts/bin/clang
failed with exit code 255

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 00:30:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:30:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9819] Unable to build 2.9 on OS X (10.6)
In-Reply-To: <bug-9819-206@http.llvm.org/bugs/>
References: <bug-9819-206@http.llvm.org/bugs/>
Message-ID: <20110522053004.1070C2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-05-22 00:30:03 CDT ---
Fixed on trunk

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

From bugzilla-daemon at llvm.org  Sun May 22 00:36:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:36:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9769] Add Redhat Enterprise Linux to the Linux
	toolchain
In-Reply-To: <bug-9769-206@http.llvm.org/bugs/>
References: <bug-9769-206@http.llvm.org/bugs/>
Message-ID: <20110522053640.3E0EC2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 00:36:39 CDT ---
Applied in r131840.  Please send patches to the -commits list so they get
reviewed and applied, and not 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  Sun May 22 00:37:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:37:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9761] AsmPrinter::EmitEndOfAsmFile is not the final
 code emission point.
In-Reply-To: <bug-9761-206@http.llvm.org/bugs/>
References: <bug-9761-206@http.llvm.org/bugs/>
Message-ID: <20110522053711.A12CC2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-05-22 00:37:11 CDT ---
Micah, please send patches to the commits list.  Do not file bugs with patches
because they get lost and not reviewed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 00:45:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:45:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9408] Missed optimization: branch to duplicate code
In-Reply-To: <bug-9408-206@http.llvm.org/bugs/>
References: <bug-9408-206@http.llvm.org/bugs/>
Message-ID: <20110522054525.E6CB92A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 00:45:25 CDT ---
I moved this microoptimization to the readme file in r131841.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 00:49:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:49:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9397] wrong source location for inline asm from
	macro
In-Reply-To: <bug-9397-206@http.llvm.org/bugs/>
References: <bug-9397-206@http.llvm.org/bugs/>
Message-ID: <20110522054947.69D3A2A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 00:49:46 CDT ---
No, I won't do this.  We get this right if you put the \t for the line in the
macro, since we track the start of each line.  We're not going to track the
location of each character, sorry.

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

From bugzilla-daemon at llvm.org  Sun May 22 00:52:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:52:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9379] MC assembler doesn't recognize inl (%%dx)
In-Reply-To: <bug-9379-206@http.llvm.org/bugs/>
References: <bug-9379-206@http.llvm.org/bugs/>
Message-ID: <20110522055208.5A73C2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2011-05-22 00:52:07 CDT ---
We already accept enough of these broken forms, we shouldn't add this 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  Sun May 22 00:53:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:53:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9375] __private_extern__ should not be recognized
 on non-Darwin platforms
In-Reply-To: <bug-9375-206@http.llvm.org/bugs/>
References: <bug-9375-206@http.llvm.org/bugs/>
Message-ID: <20110522055334.B85A42A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 00:53:34 CDT ---
Clang accepts this as an extension on other platforms.  The libdispatch
configure script should figure this out some other way.

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

From bugzilla-daemon at llvm.org  Sun May 22 00:55:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:55:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9365] never use integrated-as on gcc output
In-Reply-To: <bug-9365-206@http.llvm.org/bugs/>
References: <bug-9365-206@http.llvm.org/bugs/>
Message-ID: <20110522055512.5FD012A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 00:55:11 CDT ---
We can't tell if a .s file is "gcc produced" until we start processing 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 May 22 00:55:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:55:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9343] top 10 missed optimizations at -O2
In-Reply-To: <bug-9343-206@http.llvm.org/bugs/>
References: <bug-9343-206@http.llvm.org/bugs/>
Message-ID: <20110522055549.BAA3F2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #14 from Chris Lattner <clattner at apple.com> 2011-05-22 00:55:48 CDT ---
What's going on with this bug?  It seems like Nick's personal todo list, not
something actionable.  If nothing else it should be moved out to a readme.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 00:57:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 00:57:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9330] [MC] Overly large encoding for orl with
	memory operand
In-Reply-To: <bug-9330-206@http.llvm.org/bugs/>
References: <bug-9330-206@http.llvm.org/bugs/>
Message-ID: <20110522055737.A731E2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 00:57:37 CDT ---
This looks like it got fixed along the way:

$ llvm-mc t.s -show-encoding  -triple i386-unknown-unknown
    .section    __TEXT,__text,regular,pure_instructions
    orl    $-1, 1                  # encoding:
[0x83,0x0d,0x01,0x00,0x00,0x00,0xff]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 01:01:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 01:01:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9297] Bad movaps code emitted when string arrays
 exist in function scope, in binary linkage
In-Reply-To: <bug-9297-206@http.llvm.org/bugs/>
References: <bug-9297-206@http.llvm.org/bugs/>
Message-ID: <20110522060144.7A7D02A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 01:01:43 CDT ---
I'm not seeing anything bad generated at -O3.  The optimizer doesn't do
anything at -O0 which is your likely issue.  If this is still a problem, please
reopen with *specific* instructions on how to repro.

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

From bugzilla-daemon at llvm.org  Sun May 22 01:04:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 01:04:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8893] Build warning in APInt.cpp while building
 trunk on DragonflyBSD current.
In-Reply-To: <bug-8893-206@http.llvm.org/bugs/>
References: <bug-8893-206@http.llvm.org/bugs/>
Message-ID: <20110522060401.2784A2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-05-22 01:04:00 CDT ---
Fixed in r131842

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 01:06:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 01:06:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8593] loop-unroll and unroll-count options do not
 work unless loop-rotate option is passed
In-Reply-To: <bug-8593-206@http.llvm.org/bugs/>
References: <bug-8593-206@http.llvm.org/bugs/>
Message-ID: <20110522060619.691212A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 01:06:18 CDT ---
This is as expected.  Loop rotation is required to put the loops into canonical
form.  Passes are not expected to work on any possible input, they have a
desired place in the pass pipeline.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 01:06:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 01:06:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8583] internalconstant is invalid bitcode signature
 in helloworld example
In-Reply-To: <bug-8583-206@http.llvm.org/bugs/>
References: <bug-8583-206@http.llvm.org/bugs/>
Message-ID: <20110522060655.9B5342A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 01:06:55 CDT ---
This 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 May 22 01:12:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 01:12:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5441] Load not simplified in spite of
	llvm.invariant.start/end
In-Reply-To: <bug-5441-206@http.llvm.org/bugs/>
References: <bug-5441-206@http.llvm.org/bugs/>
Message-ID: <20110522061235.A94972A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-05-22 01:12:34 CDT ---
invariant sections are really implemented yet, and probably have to be
redesigned before they work out 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 May 22 02:03:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 02:03:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9841] Infinite loop in GVN
In-Reply-To: <bug-9841-206@http.llvm.org/bugs/>
References: <bug-9841-206@http.llvm.org/bugs/>
Message-ID: <20110522070355.B33322A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 02:03:55 CDT ---
Fixed in r131847, 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 May 22 02:15:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 02:15:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9856] Assertion `(isa<PHINode>(GlobalUser) ||
 isa<SelectInst>(GlobalUser) || isa<ConstantExpr>(GlobalUser)) && "Only
 expect load and stores!"' failed.
In-Reply-To: <bug-9856-206@http.llvm.org/bugs/>
References: <bug-9856-206@http.llvm.org/bugs/>
Message-ID: <20110522071526.ADE102A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 02:15:26 CDT ---
Fixed in r131849, thanks John.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 02:18:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 02:18:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9935] insertvalue syntax in Language Reference
 Manual does not show it being vararg.
In-Reply-To: <bug-9935-206@http.llvm.org/bugs/>
References: <bug-9935-206@http.llvm.org/bugs/>
Message-ID: <20110522071817.E41AB2A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 02:18:17 CDT ---
Fixed in r131850, 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 May 22 03:02:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 03:02:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9983] New: clang crashes when using std::bind with
 a non-static method
Message-ID: <bug-9983-206@http.llvm.org/bugs/>

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

           Summary: clang crashes when using std::bind with a non-static
                    method
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

The following code (preprocessed version attached) crashes clang trunk with
libc++ trunk:

#include <functional>

struct Container {
    void lookup() const {}
};

void lookup(Container&) {}


template <typename Functor>
static void foo(Functor f)
{
    f();
}


int main(int, char**)
{
    Container    c;
    foo(std::bind(&Container::lookup, c));    // A
    //foo(std::bind(&lookup, c));            // B
}


$ ~/LLVM/build/Debug+Asserts/bin/clang -std=c++0x -stdlib=libc++ clang.cpp
Assertion failed: (false && "Not an overloaded operator"), function
mangleOperatorName, file
/Users/rynnsauer/LLVM/llvm/tools/clang/lib/AST/ItaniumMangle.cpp, line 1435.

(Full crash log attached)


Commenting line (A) and uncommenting line (B) results in a successful compile.

My clang version:

$ ~/LLVM/build/Debug+Asserts/bin/clang --versionclang version 3.0 (trunk
131844)
Target: x86_64-apple-darwin10.7.0
Thread model: posix


My libc++ version:

$ svn info .
[...]
Revision: 131842

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 05:25:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 05:25:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9984] New: failure of wide string literals defined
 inside a macro
Message-ID: <bug-9984-206@http.llvm.org/bugs/>

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

           Summary: failure of wide string literals defined inside a macro
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jason at filsinger.me
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


the following code produces an error:


#define TESTL(x) L#x
const wchar_t* a = L"Hello World";
const wchar_t* b = TESTL(Hello World);


The preprocessor appears to ignore the L inside the define as the literal
declaring the string as a wide string.   The code not using the macro passes
without error.

Here is the analyzer output:

"Use of undeclared identifier 'L'"

This fails on both using the analyzer that ships with XCode 4.0.1 as well as
svn trunk (test at revision 131851).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 10:27:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 10:27:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9984] failure of wide string literals defined
	inside a macro
In-Reply-To: <bug-9984-206@http.llvm.org/bugs/>
References: <bug-9984-206@http.llvm.org/bugs/>
Message-ID: <20110522152743.0366A2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-22 10:27:42 CDT ---
Clang is behaving correctly here (as does GCC). You can't both stringize a
token and concatenate in one step. Instead, use:

  #define TESTL2(x) L##x 
  #define TESTL(x) TESTL2(#x)
  const wchar_t* a = L"Hello World";
  const wchar_t* b = TESTL(Hello World);

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 12:40:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 12:40:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9815] likely wrong code bug
In-Reply-To: <bug-9815-206@http.llvm.org/bugs/>
References: <bug-9815-206@http.llvm.org/bugs/>
Message-ID: <20110522174010.210CD2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-05-22 12:40:09 CDT ---
Fixed in r131858, thanks John.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 12:52:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 12:52:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9386] ARM disassembler failed to disassemble
	conditional bx
In-Reply-To: <bug-9386-206@http.llvm.org/bugs/>
References: <bug-9386-206@http.llvm.org/bugs/>
Message-ID: <20110522175208.E914D2A6C124@llvm.org>

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

johnny.chen at apple.com changed:

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

--- Comment #2 from johnny.chen at apple.com 2011-05-22 12:52:08 CDT ---
Submitted r131859.
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 May 22 13:18:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 13:18:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9814] optimizing integer power of 2 #2
In-Reply-To: <bug-9814-206@http.llvm.org/bugs/>
References: <bug-9814-206@http.llvm.org/bugs/>
Message-ID: <20110522181857.F00932A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-05-22 13:18:57 CDT ---
Implemented in r131860, 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 May 22 13:24:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 13:24:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9985] New: Codegen fails when -gdwarf-2 is set
Message-ID: <bug-9985-206@http.llvm.org/bugs/>

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

           Summary: Codegen fails when -gdwarf-2 is set
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joshuacweinberg at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6629)
 --> (http://llvm.org/bugs/attachment.cgi?id=6629)
Code that fails

clang -gdwarf-2 x -c main.mm

Assertion failed: (!DC->isClosure()), function getNonClosureContext, file
/Users/jweinberg/Development/llvm/tools/clang/lib/AST/DeclBase.cpp, line 651.
0  clang             0x00000001048cf8e2 _ZL15PrintStackTracePv + 34
1  clang             0x00000001048cfee9 _ZL13SignalHandleri + 745
2  libsystem_c.dylib 0x00007fff8ee61d3a _sigtramp + 26
3  libsystem_c.dylib 000000000000000000 _sigtramp + 18446603338118718176
4  clang             0x00000001048cf846 abort + 22
5  clang             0x00000001048cf898 __assert_rtn + 56
6  clang             0x0000000103ddb2bc clang::Decl::CheckAccessDeclContext()
const + 0
7  clang             0x000000010391b31b
clang::CodeGen::CGDebugInfo::EmitDeclareOfBlockLiteralArgVariable(clang::CodeGen::CGBlockInfo
const&, llvm::Value*, llvm::IRBuilder<true, llvm::ConstantFolder,
llvm::IRBuilderDefaultInserter<true> >&) + 1941
8  clang             0x0000000103920267
clang::CodeGen::CodeGenFunction::EmitParmDecl(clang::VarDecl const&,
llvm::Value*, unsigned int) + 321
9  clang             0x00000001038fc8df
clang::CodeGen::CodeGenFunction::EmitFunctionProlog(clang::CodeGen::CGFunctionInfo
const&, llvm::Function*, clang::CodeGen::FunctionArgList const&) + 1025
10 clang             0x00000001039ba79f
clang::CodeGen::CodeGenFunction::StartFunction(clang::CodeGen::GlobalDecl,
clang::QualType, llvm::Function*, clang::CodeGen::CGFunctionInfo const&,
clang::CodeGen::FunctionArgList const&, clang::SourceLocation) + 1457
11 clang             0x00000001038e2120
clang::CodeGen::CodeGenFunction::GenerateBlockFunction(clang::CodeGen::GlobalDecl,
clang::CodeGen::CGBlockInfo const&, clang::Decl const*,
llvm::DenseMap<clang::Decl const*, llvm::Value*, llvm::DenseMapInfo<clang::Decl
const*>, llvm::DenseMapInfo<llvm::Value*> > const&) + 1670
12 clang             0x00000001038e4797
clang::CodeGen::CodeGenFunction::EmitBlockLiteral(clang::BlockExpr const*) +
335
13 clang             0x0000000103955083 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
10137
14 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
15 clang             0x00000001039641dd
clang::CodeGen::CodeGenFunction::EmitObjCMessageExpr(clang::ObjCMessageExpr
const*, clang::CodeGen::ReturnValueSlot) + 165
16 clang             0x0000000103957694 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
19882
17 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
18 clang             0x00000001039641dd
clang::CodeGen::CodeGenFunction::EmitObjCMessageExpr(clang::ObjCMessageExpr
const*, clang::CodeGen::ReturnValueSlot) + 165
19 clang             0x0000000103957694 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
19882
20 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
21 clang             0x000000010399becb
clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) + 333
22 clang             0x000000010399cbdf
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 637
23 clang             0x000000010399f58c
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 244
24 clang             0x000000010399ce5a
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 146
25 clang             0x000000010399c98b
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 41
26 clang             0x00000001038e24dc
clang::CodeGen::CodeGenFunction::GenerateBlockFunction(clang::CodeGen::GlobalDecl,
clang::CodeGen::CGBlockInfo const&, clang::Decl const*,
llvm::DenseMap<clang::Decl const*, llvm::Value*, llvm::DenseMapInfo<clang::Decl
const*>, llvm::DenseMapInfo<llvm::Value*> > const&) + 2626
27 clang             0x00000001038e4797
clang::CodeGen::CodeGenFunction::EmitBlockLiteral(clang::BlockExpr const*) +
335
28 clang             0x0000000103955083 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
10137
29 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
30 clang             0x00000001039641dd
clang::CodeGen::CodeGenFunction::EmitObjCMessageExpr(clang::ObjCMessageExpr
const*, clang::CodeGen::ReturnValueSlot) + 165
31 clang             0x0000000103957694 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
19882
32 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
33 clang             0x00000001039641dd
clang::CodeGen::CodeGenFunction::EmitObjCMessageExpr(clang::ObjCMessageExpr
const*, clang::CodeGen::ReturnValueSlot) + 165
34 clang             0x0000000103957694 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
19882
35 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
36 clang             0x000000010399becb
clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) + 333
37 clang             0x000000010399cbdf
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 637
38 clang             0x000000010399f58c
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 244
39 clang             0x000000010399ce5a
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 146
40 clang             0x000000010399c98b
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 41
41 clang             0x00000001038e24dc
clang::CodeGen::CodeGenFunction::GenerateBlockFunction(clang::CodeGen::GlobalDecl,
clang::CodeGen::CGBlockInfo const&, clang::Decl const*,
llvm::DenseMap<clang::Decl const*, llvm::Value*, llvm::DenseMapInfo<clang::Decl
const*>, llvm::DenseMapInfo<llvm::Value*> > const&) + 2626
42 clang             0x00000001038e4797
clang::CodeGen::CodeGenFunction::EmitBlockLiteral(clang::BlockExpr const*) +
335
43 clang             0x0000000103955083 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
10137
44 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
45 clang             0x00000001039641dd
clang::CodeGen::CodeGenFunction::EmitObjCMessageExpr(clang::ObjCMessageExpr
const*, clang::CodeGen::ReturnValueSlot) + 165
46 clang             0x0000000103957694 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
19882
47 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
48 clang             0x00000001039641dd
clang::CodeGen::CodeGenFunction::EmitObjCMessageExpr(clang::ObjCMessageExpr
const*, clang::CodeGen::ReturnValueSlot) + 165
49 clang             0x0000000103957694 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
19882
50 clang             0x000000010395d23e (anonymous
namespace)::ScalarExprEmitter::EmitCastExpr(clang::CastExpr*) + 494
51 clang             0x000000010395582f clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
12101
52 clang             0x000000010394d74f
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 95
53 clang             0x000000010399becb
clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) + 333
54 clang             0x000000010399cbdf
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 637
55 clang             0x000000010399f58c
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 244
56 clang             0x000000010399ce5a
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 146
57 clang             0x000000010399c98b
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 41
58 clang             0x00000001039bab3a
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 662
59 clang             0x00000001039c18fc
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl)
+ 2452
60 clang             0x00000001039c2680
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 396
61 clang             0x00000001039c33bd
clang::CodeGen::CodeGenModule::EmitDeferred() + 159
62 clang             0x00000001039c36f2
clang::CodeGen::CodeGenModule::Release() + 20
63 clang             0x00000001039b7835
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 93
64 clang             0x00000001039d7acf clang::ParseAST(clang::Sema&, bool) +
431
65 clang             0x00000001039b68ec clang::CodeGenAction::ExecuteAction() +
874
66 clang             0x00000001037f2b21
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 947
67 clang             0x00000001037cde87
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1863
68 clang             0x00000001037c831b cc1_main(char const**, char const**,
char const*, void*) + 2779
69 clang             0x00000001037cae70 main + 640
70 clang             0x00000001037c7834 start + 52
71 clang             0x000000000000002c start + 18446744069356095532
Stack dump:
0.    Program arguments:
/Users/jweinberg/Development/llvm/build/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free -main-file-name
main.mm -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 123.2.1 -g -coverage-file main.o
-resource-dir
/Users/jweinberg/Development/llvm/build/Release+Asserts/bin/../lib/clang/3.0
-std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 176
-stack-protector 1 -fblocks -fobjc-exceptions -fcxx-exceptions -fexceptions
-fobjc-nonfragile-abi -fobjc-dispatch-method=mixed -fdiagnostics-show-option
-fcolor-diagnostics -o main.o -x objective-c++
/Users/jweinberg/Development/LLVMCrash/LLVMCrash/main.mm 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    /Users/jweinberg/Development/LLVMCrash/LLVMCrash/main.mm:16:5: Generating
code for declaration 'Curry<int (^)(int, int, int)>::operator int
(^(^(^)(int))(int))(int)'
4.    /Users/jweinberg/Development/LLVMCrash/LLVMCrash/main.mm:17:5: LLVM IR
generation of compound statement ('{}')
5.    /Users/jweinberg/Development/LLVMCrash/LLVMCrash/main.mm:18:27: LLVM IR
generation of compound statement ('{}')
6.    /Users/jweinberg/Development/LLVMCrash/LLVMCrash/main.mm:19:31: LLVM IR
generation of compound statement ('{}')
clang: error: unable to execute command: Illegal instruction: 4
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  Sun May 22 13:49:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 13:49:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9986] New: -s (strip) missing from command-line
	options
Message-ID: <bug-9986-206@http.llvm.org/bugs/>

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

           Summary: -s (strip) missing from command-line options
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: greg.toombs at bluebottle.com
                CC: llvmbugs at cs.uiuc.edu


I'm using this release on Ubuntu:

clang version 2.8 (branches/release_28)
Target: x86_64-pc-linux-gnu
Thread model: posix

It's missing -s. My current workaround is to use -Wl,-s to manually get the
linker to strip the symbol 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  Sun May 22 17:02:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 17:02:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9987] New: -Wextra overrides earlier
	-Wno-sign-compare
Message-ID: <bug-9987-206@http.llvm.org/bugs/>

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

           Summary: -Wextra overrides earlier -Wno-sign-compare
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


For GCC, the -Wall and -Wextra (aka -W) options are supposed to set the warning
defaults and -Wno-* can be used to disable options again. This doesn't work as
expected with clang.

Consider the following input:

int main(void)
{
    int a = 0;
    unsigned int b = 1;
    return a < b ? 1 : 2;
}

clang -Wextra -Wno-sign-compare -c test.c
is silent.

clang -Wno-sign-compare -Wextra -c test.c
warns, when it should be silent (and the diagnostic message is kind of
confusion).

GCC doesn't warn in either 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  Sun May 22 17:10:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 17:10:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9861] clang -E produces output that clang doesn't
	like
In-Reply-To: <bug-9861-206@http.llvm.org/bugs/>
References: <bug-9861-206@http.llvm.org/bugs/>
Message-ID: <20110522221027.7894D2A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 17:10:26 CDT ---
Fixed in r131871, 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 May 22 17:22:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 17:22:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9315] pow() isn't folded
In-Reply-To: <bug-9315-206@http.llvm.org/bugs/>
References: <bug-9315-206@http.llvm.org/bugs/>
Message-ID: <20110522222246.784062A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #6 from Chris Lattner <clattner at apple.com> 2011-05-22 17:22:45 CDT ---
Implemented in r131872.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 17:29:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 17:29:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9101] Missing 'thiscall' calling convention in
	LangRef.html
In-Reply-To: <bug-9101-206@http.llvm.org/bugs/>
References: <bug-9101-206@http.llvm.org/bugs/>
Message-ID: <20110522222900.D56292A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 17:29:00 CDT ---
Documented here:
http://llvm.org/docs/CodeGenerator.html#x86_cc

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

From bugzilla-daemon at llvm.org  Sun May 22 17:33:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 17:33:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9378] MC assembler doesn't handle fsubp %st, %st(1)
In-Reply-To: <bug-9378-206@http.llvm.org/bugs/>
References: <bug-9378-206@http.llvm.org/bugs/>
Message-ID: <20110522223310.119F22A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #3 from Chris Lattner <clattner at apple.com> 2011-05-22 17:33:09 CDT ---
patch applied in r131874 with testcase in 131875.  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 May 22 17:35:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 17:35:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9164] [MC] fsubp invalid operand for instruction
In-Reply-To: <bug-9164-206@http.llvm.org/bugs/>
References: <bug-9164-206@http.llvm.org/bugs/>
Message-ID: <20110522223543.7E7232A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #7 from Chris Lattner <clattner at apple.com> 2011-05-22 17:35:42 CDT ---
We now accept this, testcase in r131876

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 17:45:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 17:45:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9987] -Wextra overrides earlier -Wno-sign-compare
In-Reply-To: <bug-9987-206@http.llvm.org/bugs/>
References: <bug-9987-206@http.llvm.org/bugs/>
Message-ID: <20110522224532.B42602A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-05-22 17:45:32 CDT ---
We don't (in general) try to be exactly identical to GCC's policies w.r.t.
warnings.  This behaves this way because clang puts -Wsign-compare into the
-Wextra category.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 22 17:49:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 17:49:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9306] Assertion failed: (OrigPreheader && OrigLatch
 && "Loop not in canonical form?"), function rotateLoop, file
 /a/portbuild/amd64/9/builds/20110221064547.pointyhat-west/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/LoopRotation.c
In-Reply-To: <bug-9306-206@http.llvm.org/bugs/>
References: <bug-9306-206@http.llvm.org/bugs/>
Message-ID: <20110522224900.A26D42A6C124@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-05-22 17:49:00 CDT ---
This works for me with mainline, it's probably been 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 May 22 20:10:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 22 May 2011 20:10:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9988] New: coppro asked me to file this bug.
Message-ID: <bug-9988-206@http.llvm.org/bugs/>

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

           Summary: coppro asked me to file this bug.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: endiannesz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


<Endiannes> clang, template<typename T> void secret_cow_level(); int main() {
secret_cow_level<void>(); }
<clang> LLVM ERROR: Program used external function '_Z16secret_cow_levelIvEvv'
which could not be resolved! [+ 1 discarded line]
<coppro> Endiannes: please file a bug

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

From bugzilla-daemon at llvm.org  Mon May 23 01:15:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 01:15:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9989] New: Wrong point of declaration for static
	data member
Message-ID: <bug-9989-206@http.llvm.org/bugs/>

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

           Summary: Wrong point of declaration for static data member
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I cannot see anything in the FDIS that makes the following invalid:

    struct A { 
      static int const B = sizeof B; 
    };

The PoD should should be immediately after "B" and before the initializer, as
far as I can see, so this is valid 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 May 23 10:39:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 10:39:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9176] ARM assertion failed when disassembling LDR &
 STR imm offset form
In-Reply-To: <bug-9176-206@http.llvm.org/bugs/>
References: <bug-9176-206@http.llvm.org/bugs/>
Message-ID: <20110523153905.66E022A6C124@llvm.org>

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

Jyun-Yan You <jyyou.tw at gmail.com> changed:

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

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

From bugzilla-daemon at llvm.org  Mon May 23 10:39:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 10:39:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9935] insertvalue syntax in Language Reference
 Manual does not show it being vararg.
In-Reply-To: <bug-9935-206@http.llvm.org/bugs/>
References: <bug-9935-206@http.llvm.org/bugs/>
Message-ID: <20110523153953.28F9C2A6C12C@llvm.org>

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

Michael Ilseman <michael at lunarg.com> changed:

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

--- Comment #2 from Michael Ilseman <michael at lunarg.com> 2011-05-23 10:39:52 CDT ---
The <idx> inside the {}s is missing in insertvalue, whereas extractvalue has
it.

<result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx>{, }*    ;
yields <aggregate type>

<result> = extractvalue <aggregate type> <val>, <idx>{, <idx>}*

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

From bugzilla-daemon at llvm.org  Mon May 23 10:44:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 10:44:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9990] New: Driver/hello.c failing after svn update
Message-ID: <bug-9990-206@http.llvm.org/bugs/>

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

           Summary: Driver/hello.c failing after svn update
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: apacherulzz at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


I recently filed bug 9972 ( http://llvm.org/bugs/show_bug.cgi?id=9972 ). I am
not sure if this is a result of errors in my build but I am not getting a new
error after updating from trunk this morning (fails Clang :: Driver/hello.c)

********************
Testing Time: 54.05s
********************
Failing Tests (9):
    Clang :: CodeGen/mmx-builtins.c
    Clang :: CodeGen/mmx-inline-asm.c
    Clang :: CodeGen/vector.c
    Clang :: Driver/hello.c
    Clang :: Headers/c89.c
    Clang :: Headers/stdbool.cpp
    Clang :: Headers/x86-intrinsics-headers.c
    Clang :: Preprocessor/header_lookup1.c
    Clang :: Sema/x86-builtin-palignr.c

  Expected Passes    : 3088
  Expected Failures  : 22
  Unexpected Failures: 9
make[1]: *** [all] Error 1
make[1]: Leaving directory `/opt/llvm/build/tools/clang/test'
make: *** [test] Error 2


OUTPUT FROM HELLO.C Error:

********************
FAIL: Clang :: Driver/hello.c (1376 of 3119)
******************** TEST 'Clang :: Driver/hello.c' FAILED ********************
Script:
--
/opt/llvm/build/Release+Asserts/bin/clang  -ccc-echo -o
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.exe
/opt/llvm/llvm/tools/clang/test/Driver/hello.c 2>
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.log
grep 'clang\(-[0-9.]\+\)\?\(\.[Ee][Xx][Ee]\)\?" -cc1 .*hello.c'
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.log
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.exe >
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.out
grep "I'm a little driver, short and stout."
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.out
--
Exit Code: 1



I have had all other errors since installing clang and am trying to get these
resolved in another bug report, however I am used GCC 4.4.4 when compiling and
am in the CentOS5 environment which is all supported so I certainly shouldn't
be getting more issues (at least I wouldn't think).

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

From bugzilla-daemon at llvm.org  Mon May 23 12:16:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 12:16:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9988] coppro asked me to file this bug.
In-Reply-To: <bug-9988-206@http.llvm.org/bugs/>
References: <bug-9988-206@http.llvm.org/bugs/>
Message-ID: <20110523171639.B57B62A6C124@llvm.org>

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

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> 2011-05-23 12:16:39 CDT ---
"Program used external function" is a JIT error message. Indeed
secret_cow_level has a declaration but no definition. It looks like clang
compiled the code fine then sent it to the JIT which failed to find a
definition for that function.

Also the mangling appears to be correct, and the code appears to be valid, in
case either of those were supposed to be the bug.

Closing as working-as-intended, but feel free to reopen with an explanation of
what the actual bug is.

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

From bugzilla-daemon at llvm.org  Mon May 23 12:21:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 12:21:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9991] New: Compile segfaults in valid code with -O3
Message-ID: <bug-9991-206@http.llvm.org/bugs/>

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

           Summary: Compile segfaults in valid code with -O3
           Product: clang
           Version: unspecified
          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=6631)
 --> (http://llvm.org/bugs/attachment.cgi?id=6631)
failing testcase

The attached code compiles fine with no optimisation, -O and -O2, but causes a
compiler segfault at -O3. This code comes from a test in boost::date_time.

clang: /home/caj/clang/llvm-debug/include/llvm/Analysis/LoopInfo.h:458: void
llvm::LoopBase<N, M>::verifyLoop() const [with BlockT = llvm::BasicBlock, LoopT
= llvm::Loop]: Assertion `HasInsideLoopSuccs && "Loop block has no in-loop
successors!"' failed.
0  clang           0x0000000002612846
1  clang           0x0000000002612642
2  libpthread.so.0 0x00007fd40c355c60
3  libc.so.6       0x00007fd40b640d05 gsignal + 53
4  libc.so.6       0x00007fd40b644ab6 abort + 390
5  libc.so.6       0x00007fd40b6397c5 __assert_fail + 245
6  clang           0x00000000023e06fc llvm::LoopBase<llvm::BasicBlock,
llvm::Loop>::verifyLoop() const + 1170
7  clang           0x00000000023e3eb9
llvm::LPPassManager::runOnFunction(llvm::Function&) + 1441
8  clang           0x000000000253cb71
llvm::FPPassManager::runOnFunction(llvm::Function&) + 445
9  clang           0x000000000239cbd9
10 clang           0x000000000239d9e3
11 clang           0x000000000239dcc6
12 clang           0x000000000253d0e0
llvm::MPPassManager::runOnModule(llvm::Module&) + 456
13 clang           0x000000000253d5d2 llvm::PassManagerImpl::run(llvm::Module&)
+ 130
14 clang           0x000000000253d9d9 llvm::PassManager::run(llvm::Module&) +
39
15 clang           0x00000000012fcafb
16 clang           0x00000000012fcc01
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 123
17 clang           0x00000000012fa068
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 460
18 clang           0x00000000014575ea clang::ParseAST(clang::Sema&, bool) + 670
19 clang           0x00000000011c6537 clang::ASTFrontendAction::ExecuteAction()
+ 263
20 clang           0x00000000012f94db clang::CodeGenAction::ExecuteAction() +
927
21 clang           0x00000000011c6193 clang::FrontendAction::Execute() + 325
22 clang           0x00000000011ad03b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 741
23 clang           0x0000000001155303
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 909
24 clang           0x000000000114679a cc1_main(char const**, char const**, char
const*, void*) + 952
25 clang           0x0000000001150a63 main + 496
26 libc.so.6       0x00007fd40b62beff __libc_start_main + 255
27 clang           0x0000000001145e69
Stack dump:
0.      Program arguments: /llvmdebug/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name t.cc
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.21.51.20110409
-momit-leaf-frame-pointer -resource-dir /llvmdebug/bin/../lib/clang/3.0 -O3
-fdeprecated-macro -ferror-limit 19 -fmessage-length 126 -fcxx-exceptions
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-PV5AIg.o -x c++ t.cc 
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module 't.cc'.
4.      Running pass 'Loop Pass Manager' on function
'@_Z8get_dateI5dateXI4date18gregorian_calendar13date_durationEEiT_'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Mon May 23 12:36:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 12:36:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9817] DAG Combiner does not preserve debug
	information
In-Reply-To: <bug-9817-206@http.llvm.org/bugs/>
References: <bug-9817-206@http.llvm.org/bugs/>
Message-ID: <20110523173642.9B5B52A6C12E@llvm.org>

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

Devang Patel <dpatel at apple.com> changed:

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

--- Comment #3 from Devang Patel <dpatel at apple.com> 2011-05-23 12:36:42 CDT ---
Thanks for small testcase and candidate patch. It is better to transfer
SDDbgValue during SelectionDAG::ReplaceAllUsesWith(). Fixed in r131907.

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

From bugzilla-daemon at llvm.org  Mon May 23 12:45:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 12:45:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9879] SelectionDAGBuilder does not preserve debug
 information attached to phi nodes
In-Reply-To: <bug-9879-206@http.llvm.org/bugs/>
References: <bug-9879-206@http.llvm.org/bugs/>
Message-ID: <20110523174511.060BF2A6C12C@llvm.org>

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

Devang Patel <dpatel at apple.com> changed:

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

--- Comment #2 from Devang Patel <dpatel at apple.com> 2011-05-23 12:45:10 CDT ---
I applied your patch. r131908.

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

From bugzilla-daemon at llvm.org  Mon May 23 13:41:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 13:41:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9992] New: clang -cc1 -fdelayed-template-parsing
 -emit-pch does not save template contents in PCH
Message-ID: <bug-9992-206@http.llvm.org/bugs/>

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

           Summary: clang -cc1 -fdelayed-template-parsing -emit-pch does
                    not save template contents in PCH
           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


$ echo 'template<typename T> void f() { i can put anything here }' | clang++
-cc1 -x c++ -fdelayed-template-parsing -emit-pch -o tmp.pch
$ echo 'template<typename T> void g() { f<T>(); } int n = (g<int>(), 0);' |
./clang++ -cc1 -x c++ -fdelayed-template-parsing -include-pch tmp.pch
-emit-llvm -o - | grep _Z1fIiEvv
  call void @_Z1fIiEvv()
declare void @_Z1fIiEvv()

Oops. It looks like the tokens for 'f' are neither parsed nor saved in the PCH
file, resulting in us silently losing 'f's definition.

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

From bugzilla-daemon at llvm.org  Mon May 23 14:49:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 14:49:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9993] New: Enum with explicit enum-base is not
	promoted to int
Message-ID: <bug-9993-206@http.llvm.org/bugs/>

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

           Summary: Enum with explicit enum-base is not promoted to int
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following program fails to compile with clang r131897:

//enum e: unsigned int {      // (A)
enum e: unsigned short {  // (B)
    A,
    B,
    C
};

int main(int, char**)
{
    e    a = A;
    return a > 0;
}


The error message is: "use of overloaded operator '>' is ambiguous (with
operand types 'e' and 'int')"


As integral promotions can promote "a" to both "unsigned short" (the enum-base)
and "int" (the promoted enum-base), the latter being the type of the "0" that
"a" is being compared with, this code should compile (and return false/0).

When line (A) is replaced by line (B), the code compiles.


On cfe-dev, Johannes Schaub posted another program that fails to compile as
well (<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-May/015220.html>):

enum e : unsigned short { };
void f(int); // should take this
void f(long);

int main() {
 e e1;
 f(e1);
}


In this case, the error message is: "call to 'f' is ambiguous".

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

From bugzilla-daemon at llvm.org  Mon May 23 15:22:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 15:22:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9994] New: assertion "isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"" failed
Message-ID: <bug-9994-206@http.llvm.org/bugs/>

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

           Summary: assertion "isa<X>(Val) && "cast<Ty>() argument of
                    incompatible type!"" failed
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: js-llvm-bugzilla at webkeks.org
                CC: llvmbugs at cs.uiuc.edu


assertion "isa<X>(Val) && "cast<Ty>() argument of incompatible type!"" failed:
file "/encrypted/home/js/llvm/include/llvm/Support/Casting.h", line 194,
function "typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&)
[with X = llvm::Function, Y = llvm::Constant*]"
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-netbsd5.1.0. -emit-llvm-bc -disable-free -main-file-name
OFXMLParser.m -pic-level 2 -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.16.1 -momit-leaf-frame-pointer -g -coverage-file OFXMLParser.lib.o
-resource-dir /usr/local/bin/../lib/clang/3.0 -D PIC -I . -I .. -I exceptions
-O2 -Wall -Wwrite-strings -Wcast-align -Wpointer-arith -Werror -std=gnu99
-fconst-strings -fconstant-string-class OFConstantString -ferror-limit 19
-fmessage-length 80 -fblocks -fobjc-exceptions -fexceptions -fgnu-runtime
-fno-constant-cfstrings -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -o OFXMLParser.lib.o -x objective-c OFXMLParser.m
1.      OFXMLParser.m:1078:1: current parser token '@'
2.      OFXMLParser.m:121:1: LLVM IR generation of declaration 'OFXMLParser'
clang: error: unable to execute command: Abort trap (core dumped)
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)

Clang won't even produce a perprocessed file with -emit-llvm

Source file:
https://webkeks.org/hg/objfw/file/e05eea44c5c2/src/OFXMLParser.m

clang version 3.0 (trunk 131912)

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

From bugzilla-daemon at llvm.org  Mon May 23 16:08:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 16:08:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9845] [LSR] clang crash with floating point
	exception
In-Reply-To: <bug-9845-206@http.llvm.org/bugs/>
References: <bug-9845-206@http.llvm.org/bugs/>
Message-ID: <20110523210800.845C52A6C12E@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #2 from Dan Gohman <gohman at apple.com> 2011-05-23 16:08:00 CDT ---
Fixed in r131919.

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

From bugzilla-daemon at llvm.org  Mon May 23 16:08:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 16:08:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9965] default constructor not emitted for templated
	class
In-Reply-To: <bug-9965-206@http.llvm.org/bugs/>
References: <bug-9965-206@http.llvm.org/bugs/>
Message-ID: <20110523210836.6E62B2A6C12C@llvm.org>

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

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

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

--- Comment #1 from Sean Hunt <scshunt at csclub.uwaterloo.ca> 2011-05-23 16:08:35 CDT ---
Fixed in R131920

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

From bugzilla-daemon at llvm.org  Mon May 23 16:13:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 16:13:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6042] Assembly Language Reference lacks 'exp' and
 'log' and friends
In-Reply-To: <bug-6042-206@http.llvm.org/bugs/>
References: <bug-6042-206@http.llvm.org/bugs/>
Message-ID: <20110523211320.844CE2A6C12D@llvm.org>

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

Dan Gohman <gohman at apple.com> changed:

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

--- Comment #5 from Dan Gohman <gohman at apple.com> 2011-05-23 16:13:20 CDT ---
Done.

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

From bugzilla-daemon at llvm.org  Mon May 23 17:33:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 17:33:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9995] New: Malformed DWARF from llc?
Message-ID: <bug-9995-206@http.llvm.org/bugs/>

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

           Summary: Malformed DWARF from llc?
           Product: libraries
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: markleone at gmail.com
                CC: llvmbugs at cs.uiuc.edu


It looks like llc might be producing malformed DWARF debug info.  I'm no DWARF
expert, so I'm having trouble diagnosing it.  Here's an example:  compile this
to LLVM IR with "clang -c -g -emit-llvm":

  void bar();
  void foo() { bar(); }    

Then generate an object file via "llc" and "as".  Running "dumpbin" on the
resulting object file (linux elf-64) gives errors like:

  AT of 16359 (0x3fe7) is unknown to dwarfdump. Continuing. 
  ...
  dwarfdump ERROR:  dwarf_srclines:  DW_DLE_ATTR_FORM_BAD (114)

There aren't any issues if the object file is generated directly by clang.  But
I need to preserve debug info from LLVM IR through llc (scenario: use clang to
compile library code with debug info, generate additional IR and link it with
library IR, then finish codegen with llc and as).  Thanks in advance for any
suggestions.

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

From bugzilla-daemon at llvm.org  Mon May 23 17:35:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 17:35:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9994] assertion "isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"" failed
In-Reply-To: <bug-9994-206@http.llvm.org/bugs/>
References: <bug-9994-206@http.llvm.org/bugs/>
Message-ID: <20110523223509.A1F152A6C12D@llvm.org>

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

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

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

--- Comment #8 from David Chisnall <csdavec at swan.ac.uk> 2011-05-23 17:35:08 CDT ---
(In reply to comment #7)
> David: is the GNU runtime still your domain?

Yup.  The problem seems to be that this module declares the property get
function as having a BOOL as the final argument.  BOOL is a typedef for
unsigned char, which becomes i8 in LLVM.  CGObjCGNU tries to construct the
function as having BoolTy (from) ASTContext as the final argument.  This is i1,
so it gets a bitcast, and then fails when trying to cast the constant bitcast
to a Function.

I've 'fixed' this (r131930) by turning a load of Functions into Constants, but
this is hiding the real problem: that we are using BoolTy (i1) in a lot of
places to represent BOOL, and hoping that something lower down will fix it. 
This may well break on some platforms, depending on what LLVM does.

We should probably just use unsigned char / i8 instead of BoolTy for ObjC
BOOLs.  This will break VxWorks with the GCC runtime, but I don't think anyone
cares.

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

From bugzilla-daemon at llvm.org  Mon May 23 18:17:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 18:17:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9994] assertion "isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"" failed
In-Reply-To: <bug-9994-206@http.llvm.org/bugs/>
References: <bug-9994-206@http.llvm.org/bugs/>
Message-ID: <20110523231706.757D82A6C124@llvm.org>

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

Jonathan Schleifer <js-llvm-bugzilla at webkeks.org> changed:

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

--- Comment #9 from Jonathan Schleifer <js-llvm-bugzilla at webkeks.org> 2011-05-23 18:17:05 CDT ---
It seems your patch introduced a segfault in another file (at least I get this
after updating to the latest rev):

Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-netbsd5.1.0. -emit-obj -disable-free -main-file-name
OFStreamObserver.m -pic-level 2 -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.16.1 -momit-leaf-frame-pointer -g -coverage-file OFStreamObserver.lib.o
-resource-dir /usr/local/bin/../lib/clang/3.0 -D PIC -I . -I .. -I exceptions
-O2 -Wall -Wwrite-strings -Wcast-align -Wpointer-arith -Werror -std=gnu99
-fconst-strings -fconstant-string-class OFConstantString -ferror-limit 19
-fmessage-length 80 -fblocks -fobjc-exceptions -fexceptions -fgnu-runtime
-fno-constant-cfstrings -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -o OFStreamObserver.lib.o -x objective-c OFStreamObserver.m
1.      OFStreamObserver.m:278:1: current parser token '-'
2.      OFStreamObserver.m:258:1: LLVM IR generation of declaration
'OFStreamObserver::addStreamToObserveForReading:'
3.      OFStreamObserver.m:259:1: LLVM IR generation of compound statement
('{}')
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)

Preprocessed file: http://sprunge.us/aLaU

If it is not related, feel free to close again and I'll create 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  Mon May 23 19:31:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 19:31:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9996] New: clang allows multiple members to be
 initialized in a union constructor
Message-ID: <bug-9996-206@http.llvm.org/bugs/>

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

           Summary: clang allows multiple members to be initialized in a
                    union constructor
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang accepts this ill-formed code:

union U {
  int a;
  int b;
  U() : a(0), b(0) {}
};

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

From bugzilla-daemon at llvm.org  Mon May 23 19:33:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 19:33:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9997] New: error: in-class initializer is not a
 constant expression
Message-ID: <bug-9997-206@http.llvm.org/bugs/>

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

           Summary: error: in-class initializer is not a constant
                    expression
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Dave at Yost.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6632)
 --> (http://llvm.org/bugs/attachment.cgi?id=6632)
error: in-class initializer is not a constant expression

Z% clang++ --version
Apple clang version 2.0 (tags/Apple/clang-139) (based on LLVM 2.9svn)
Target: x86_64-apple-darwin10
Thread model: posix
Z% cat clang-error-in-class-initializer-is-not-a-constant-expression.cpp

template<int v>
class foo {
public:
    static const int width;
};

template<int v> const int foo<v>::width = 1;

struct bar {
  static const int baz = foo<255>::width;
};
Z% clang++ -c clang-error-in-class-initializer-is-not-a-constant-expression.cpp
clang-error-in-class-initializer-is-not-a-constant-expression.cpp:11:26: error:
in-class initializer is not a constant
      expression
  static const int baz = foo<255>::width;
                         ^~~~~~~~~~~~~~~
1 error generated.
Z%

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 23 19:34:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 19:34:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9997] error: in-class initializer is not a constant
	expression
In-Reply-To: <bug-9997-206@http.llvm.org/bugs/>
References: <bug-9997-206@http.llvm.org/bugs/>
Message-ID: <20110524003438.7D48D2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9997

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-23 19:34:38 CDT ---
Clang is correct to reject this code, because the initializer is not constant
unless it was written within the class definition.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 23 20:20:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 20:20:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9998] New: likely wrong code bug
Message-ID: <bug-9998-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=9998

           Summary: likely 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, chenyang at cs.utah.edu


[regehr at gamow tmp025]$ clang -O0 small.c -o small
[regehr at gamow tmp025]$ ./small
1
[regehr at gamow tmp025]$ clang -O1 small.c -o small
[regehr at gamow tmp025]$ ./small
0
[regehr at gamow tmp025]$ gcc -O1 small.c -o small
[regehr at gamow tmp025]$ ./small
1
[regehr at gamow tmp025]$ clang -v
clang version 3.0 (trunk 131944)
Target: x86_64-unknown-linux-gnu
Thread model: posix
[regehr at gamow tmp025]$ cat small.c
int printf (const char *, ...);

struct S0
{
  signed f0:1;
};

struct S0 g_122 = {
  1,
};

unsigned g_626;
int
func_55 (int p_60)
{
  unsigned long l_373 = 0x6546E4C6CD30E57BLL;
  if (g_122.f0 > l_373)
    p_60 = 1;
  return p_60;
}

int
main (void)
{
  g_626 = func_55 (0);
  printf ("%u\n", g_626);
  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  Mon May 23 20:49:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 20:49:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9994] assertion "isa<X>(Val) && "cast<Ty>()
 argument of incompatible type!"" failed
In-Reply-To: <bug-9994-206@http.llvm.org/bugs/>
References: <bug-9994-206@http.llvm.org/bugs/>
Message-ID: <20110524014912.C7C6B2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9994

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Chris Lattner <clattner at apple.com> 2011-05-23 20:49:12 CDT ---
Seems unlikely to be related, please file another bug.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 23 20:51:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 20:51:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9999] New: A simple recursive TMP static const
 initializer defeats clang.
Message-ID: <bug-9999-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=9999

           Summary: A simple recursive TMP static const initializer
                    defeats clang.
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: phorgan1 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6635)
 --> (http://llvm.org/bugs/attachment.cgi?id=6635)
Test program to illustrate the problem built with clang -c testit.cpp

clang version 2.8 (branches/release_28)
Target: i386-pc-linux-gnu
Thread model: posix

This works on gcc but not on clang:

template<unsigned int v>
class bitWidthHolding {
public:
    /** width is the number of bits occupied by the template parameter v
        */
    static const
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
};

static const int width=bitWidthHolding<255>::width;

Error is: 
patrick at dell$ clang -c testit.cpp
testit.cpp:7:67: error: in-class initializer is not an integral constant
      expression
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
testit.cpp:7:40: note: in instantiation of template class 'bitWidthHolding<0>'
      requested here
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                                       ^
testit.cpp:7:40: note: in instantiation of template class 'bitWidthHolding<1>'
      requested here
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                                       ^
testit.cpp:7:40: note: in instantiation of template class 'bitWidthHolding<3>'
      requested here
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                                       ^
testit.cpp:7:40: note: in instantiation of template class 'bitWidthHolding<7>'
      requested here
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                                       ^
testit.cpp:7:40: note: in instantiation of template class 'bitWidthHolding<15>'
      requested here
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                                       ^
testit.cpp:7:40: note: in instantiation of template class 'bitWidthHolding<31>'
      requested here
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                                       ^
testit.cpp:7:40: note: in instantiation of template class 'bitWidthHolding<63>'
      requested here
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                                       ^
testit.cpp:7:40: note: in instantiation of template class
'bitWidthHolding<127>'
      requested here
    unsigned int width = (v == 0 ? 0 : bitWidthHolding<(v >> 1)>::width + 1);
                                       ^
testit.cpp:10:24: note: in instantiation of template class
      'bitWidthHolding<255>' requested here
static const int width=bitWidthHolding<255>::width;
                       ^
1 error generated.

The real error is the top one, which should be static const int 0, and is not
recognized as const.  For us it's a showstopper, we can't use clang because of
this.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 23 21:30:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 21:30:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10000] New: Doug is Buggy
Message-ID: <bug-10000-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10000

           Summary: Doug is Buggy
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: scshunt at csclub.uwaterloo.ca
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Potentially this is better for WG21 to handle?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 23 22:21:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 23 May 2011 22:21:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9976] Crash in LiveVariables::runOnMachineFunction
 in Release builds
In-Reply-To: <bug-9976-206@http.llvm.org/bugs/>
References: <bug-9976-206@http.llvm.org/bugs/>
Message-ID: <20110524032134.1640E2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9976

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #12 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-23 22:21:33 CDT ---
Fixed in r131954, thanks Sean!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 03:29:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 03:29:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10001] New: Clang fails to instantiate an
 initializer required to complete a type
Message-ID: <bug-10001-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10001

           Summary: Clang fails to instantiate an initializer required to
                    complete a type
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Clang isn't properly instantiating templates when it is required to do so to
complete some types:

% cat x.cc                                        
template <typename T> struct S {
  static const int arr[];
  static const int x;
  static int f();
};

template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }

int x = S<int>::f();

% ./bin/clang -fsyntax-only x.cc                  
x.cc:8:43: error: invalid application of 'sizeof' to an incomplete type 'const
int []'
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
                                          ^~~~~~~~~~~
x.cc:9:46: note: in instantiation of static data member 'S<int>::x' requested
here
template <typename T> int S<T>::f() { return x; }
                                             ^
x.cc:11:17: note: in instantiation of member function 'S<int>::f' requested
here
int x = S<int>::f();
                ^
1 error generated.


It looks like this would work were the types class types, but because they're
non-class-types, we assume their completeness doesn't require instantiation.
Doh. This has nothing to do with sizeof(), this is broken in innumerable
contexts in Clang, the fundamental API for causing a type to become complete
fails to consider this scenario as far as I can tell.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 07:48:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 07:48:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10002] New: Wrongfully assuming RHS is always
	unsigned
Message-ID: <bug-10002-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10002

           Summary: Wrongfully assuming RHS is always unsigned
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: vslugovsky at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6638)
 --> (http://llvm.org/bugs/attachment.cgi?id=6638)
A simple test case which fails

CGExprScalar.cpp: EmitShl(...) may produce an integer cast for a right hand
side expression, assuming that it is unsigned. Please see the attached test
case which produces a wrong IR and a patch to fix 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  Tue May 24 08:15:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 08:15:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10003] New: SelectionDAG instruction selection
 performs CSE on nodes with debug information
Message-ID: <bug-10003-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10003

           Summary: SelectionDAG instruction selection performs CSE on
                    nodes with debug information
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6640)
 --> (http://llvm.org/bugs/attachment.cgi?id=6640)
test case that shows problem

If SelectionDAG is generating code when debug information exists and there
exists two sections of code that has the same expression but come from
different source line numbers, SelectionDAG does CSE when generating
MachineNodes. The problem is that two source line numbers might have the same
expression but when CSE is performed, only one of the debug loc values is
saved. Since the SelectionDAG does bottom-up instruction selection, the debug
loc with the line number later in the source program wins generating
non-sequential debug_loc debug information. I have attached a test case that
shows this problem.

Here is the line of code:

MachineSDNode *
SelectionDAG::getMachineNode(unsigned Opcode, DebugLoc DL, SDVTList VTs,
                             const SDValue *Ops, unsigned NumOps) {
  bool DoCSE = VTs.VTs[VTs.NumVTs-1] != MVT::Glue;
  MachineSDNode *N;
  void *IP = 0;


Adding this,  && !hasDebugValues(), to the DoCSE boolean check fixes the
problem.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 10:00:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 10:00:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10004] New: [QoI] warn about non-static, non-inline,
 non-template function definitions in header files
Message-ID: <bug-10004-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10004

           Summary: [QoI] warn about non-static, non-inline, non-template
                    function definitions in header 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: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


clang -Wall -Wextra produces no warnings for this:

// a.h
struct S {
  void f();
};

void S::f() {}

// a.cpp
#include "a.h"
void g() {
  S s;
  s.f();
}

This issue is a particular efficiency drain since it doesn't manifest until
link time, and requires a rebuild of all includers of the header.

Ideally, any definition which wholly comes from a header file and produces a
non-weak symbol should warn. We'll need to be careful to weed out macros
defined in the main source file and expanded in #included files.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 11:02:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 11:02:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9999] A simple recursive TMP static const
 initializer defeats clang.
In-Reply-To: <bug-9999-206@http.llvm.org/bugs/>
References: <bug-9999-206@http.llvm.org/bugs/>
Message-ID: <20110524160234.8A1E02A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9999

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-05-24 11:02:34 CDT ---
Fixed (for C++0x) by implementing the corresponding part of C++0x
[expr.const]p2 in Clang r131968.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 15:42:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 15:42:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9721] crash on static_assert
In-Reply-To: <bug-9721-206@http.llvm.org/bugs/>
References: <bug-9721-206@http.llvm.org/bugs/>
Message-ID: <20110524204221.0F36A2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9721

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2011-05-24 15:42:20 CDT ---
Fixed: r132001

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 16:23:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 16:23:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10005] New: DebugLoc information is lost in code
	generation
Message-ID: <bug-10005-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10005

           Summary: DebugLoc information is lost in code generation
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6642)
 --> (http://llvm.org/bugs/attachment.cgi?id=6642)
test case that looses debug information.

While attempting to find a suitable test case for bug10003, I found a test case
that looses debug information.

The debug information for line 8 is lost with the following command:
llc -march=x86 -O0 _temp_0_cypress_optimized.bc

In addition to the previous bug, line 3 is also lost with the following
command:
llc -march=x86 _temp_0_cypress_optimized.bc

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 18:13:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 18:13:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9991] Compile segfaults in valid code with -O3
In-Reply-To: <bug-9991-206@http.llvm.org/bugs/>
References: <bug-9991-206@http.llvm.org/bugs/>
Message-ID: <20110524231326.DC7392A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9991

Evan Cheng <evan.cheng at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |evan.cheng at apple.com
         Resolution|                            |FIXED

--- Comment #4 from Evan Cheng <evan.cheng at apple.com> 2011-05-24 18:13:26 CDT ---
Fixed: r132022.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 19:09:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 19:09:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9399] libc++.so: undefined reference to
	`clock_gettime'
In-Reply-To: <bug-9399-206@http.llvm.org/bugs/>
References: <bug-9399-206@http.llvm.org/bugs/>
Message-ID: <20110525000950.D5FB62A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9399

Ryuta Suzuki <oroppas at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #7 from Ryuta Suzuki <oroppas at gmail.com> 2011-05-24 19:09:50 CDT ---
I confirmed the patch committed. Thanks.

(In reply to comment #6)
> Committed revision 131961.
> 
> Close?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 19:38:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 19:38:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9762] [ARM] integrated-as fails to compile inline
	asm
In-Reply-To: <bug-9762-206@http.llvm.org/bugs/>
References: <bug-9762-206@http.llvm.org/bugs/>
Message-ID: <20110525003800.72D6E2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9762

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> 2011-05-24 19:37:59 CDT ---
Fixed in r132026!
http://llvm.org/viewvc/llvm-project?rev=132026&view=rev

Please, report more ARM assembly parser errors when you find!
Thank you!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 19:43:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 19:43:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10006] New: Behavior of Overridden Initializations
 with Designated Initializers
Message-ID: <bug-10006-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10006

           Summary: Behavior of Overridden Initializations with Designated
                    Initializers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rgamble99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When a designated initializer is used to override a previous initializer in an
initialization list and the overriding initializer does not explicitly
initialize all of the members from the previous initialization, the members not
explicitly initialized retain the values from the previous initialization. 
Instead, the values for the subobjects in the prior initialization should be
completely discarded and the subobjects not initialized in the later
initialization should be implicitly initialized.

The below program demonstrates the issue:

#include <stdio.h>

struct foo { int a, b; };

int main(void) {
    struct foo foo_array[2] =
        { {1, 2}, {3, 4}, [0] = { .a = 10 }, { .b = 40 } };
    printf("{%d, %d}, {%d, %d}\n",
        foo_array[0].a, foo_array[0].b,
        foo_array[1].a, foo_array[1].b);
    return 0;
}

When compiled with clang, the resulting program prints "{10, 2}, {3, 40}".  I
believe the correct output (as per 9889:1999 ?6.7.8p19) is "{10, 0}, {0, 40}"
and this is what gcc and Intel produce.  Tested with clang 2.9 (trunk 120076)
and clang 3.0 (trunk 131958)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 24 23:22:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 24 May 2011 23:22:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10007] New: ARM branch instructions have very
 inconsistent predicate operand placement
Message-ID: <bug-10007-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10007

           Summary: ARM branch instructions have very inconsistent
                    predicate operand placement
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


The ARM branch instructions have inconsistent predicate operand placement.
BL/tBL want the predicate before the register operand; BX/tBX want it after the
register operand; tBLXr wants it after, but tBLXr_r9 wants it before, etc.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 01:42:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 01:42:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10008] New: Clang does not work on upcoming ubuntu
	11.11
Message-ID: <bug-10008-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10008

           Summary: Clang does not work on upcoming ubuntu 11.11
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tobias.hunger at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6645)
 --> (http://llvm.org/bugs/attachment.cgi?id=6645)
Fix include pathes of clang for ubuntu 11.11

Clang does not find the header files in ubuntu oneiric ocelot (11.11). That
version uses GCC 4.6.0 and the include pathes are not picked up properly.

The attached patch fixes the issue.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 06:22:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 06:22:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10009] New: test/SemaCXX/underlying_type.cpp fails
	on x86
Message-ID: <bug-10009-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10009

           Summary: test/SemaCXX/underlying_type.cpp fails on x86
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu


Using r132050

clang:
/usr/src/packages/BUILD/llvm-clang-head-2.9.99.git20110525/include/llvm/ADT/PointerIntPair.h:80:
void llvm::PointerIntPair<void *, 1, bool, llvm::PointerUnionUIntTraits<const
clang::Type *, const clang::ExtQuals *> >::setPointer(void *): Assertion
`(PtrVal & ((1 << PtrTraits::NumLowBitsAvailable)-1)) == 0 && "Pointer is not
sufficiently aligned"' failed.
Stack dump:
0.    Program arguments:
/usr/src/packages/BUILD/llvm-clang-head-2.9.99.git20110525/stage2/bin/./clang
-cc1 -ffreestanding -fsyntax-only -verify -std=c++0x
/usr/src/packages/BUILD/llvm-clang-head-2.9.99.git20110525/tools/clang/test/SemaCXX/underlying_type.cpp
1.      
/usr/src/packages/BUILD/llvm-clang-head-2.9.99.git20110525/tools/clang/test/SemaCXX/underlying_type.cpp:25:23:
current parser token ';'
/usr/src/packages/BUILD/llvm-clang-head-2.9.99.git20110525/stage2/tools/clang/test/SemaCXX/Output/underlying_type.cpp.script:
line 1: 25788 Aborted                
/usr/src/packages/BUILD/llvm-clang-head-2.9.99.git20110525/stage2/bin/./clang
-cc1 -ffreestanding -fsyntax-only -verify -std=c++0x
/usr/src/packages/BUILD/llvm-clang-head-2.9.99.git20110525/tools/clang/test/SemaCXX/underlying_type.cpp


x86-64 is fine.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 08:56:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 08:56:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10010] New: install target performs compiling and
	linking
Message-ID: <bug-10010-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10010

           Summary: install target performs compiling and linking
           Product: Build scripts
           Version: 2.9
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: igmar at palsenberg.com
                CC: llvmbugs at cs.uiuc.edu


make install seems to be performing linking and compiling in this target after
a complete build. While it works, I think this is wrong : The install target's
only job should be putting various things in the right place.

For a packager this means that testing the install target takes ages, which
isn't nice with large packages such as llvm.
To be correct, this should 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 May 25 11:39:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 11:39:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10011] New: clang should warn on "string.empty()"
 when the return value is ignored
Message-ID: <bug-10011-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10011

           Summary: clang should warn on "string.empty()" when the return
                    value is ignored
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


#include <string>
using namespace std;

void f(string& s) {
  s.empty();
}

Chances are the programmer meant |s.clear()| instead.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 11:46:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 11:46:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10012] New: Ubuntu 11.04 Natty x86: problems
 finding system headers
Message-ID: <bug-10012-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10012

           Summary: Ubuntu 11.04 Natty x86: problems finding system
                    headers
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ofv at wanadoo.es
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6647)
 --> (http://llvm.org/bugs/attachment.cgi?id=6647)
Output of compilation

First, the headers:

#include <errno.h>
int main() { return 0; }

"clang++ -v foo.cpp" 

fails with the output shown on the attachment.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 13:53:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 13:53:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10009] test/SemaCXX/underlying_type.cpp fails on x86
In-Reply-To: <bug-10009-206@http.llvm.org/bugs/>
References: <bug-10009-206@http.llvm.org/bugs/>
Message-ID: <20110525185335.C29722A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10009

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> 2011-05-25 13:53:35 CDT ---
Fixed in Clang r132064.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 15:56:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 15:56:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10013] New: Scope of extern declarations extend
 past enclosing block
Message-ID: <bug-10013-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10013

           Summary: Scope of extern declarations extend past enclosing
                    block
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rgamble99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When multiple extern declarations for an identifier exist at block scope, the
scope of the declaration incorrectly extends past the block containing the
declaration.

For example, the following program prints 10 instead of 20 when compiled with
clang:

    #include <stdio.h>

    int i = 10;

    int main(void) {
        int i = 20;
        {
            extern int i;
            extern int i;
        }
        printf("%d\n", i);
        return 0;
    }

If one of the "extern int i;" lines is removed, 20 will be printed.  gcc and
Intel print 20 both cases.  The same issue occurs if the second extern
declaration is in a nested block:

    #include <stdio.h>

    int i = 10;

    int main(void) {
        int i = 20;
        {
            extern int i;
            {
                extern int i;
            }
        }

        printf("%d\n", i);
        return 0;
    }

This was tested with clang version 3.0 (trunk 131958).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 16:45:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 16:45:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9692] -O2 -fplugin-arg-dragonegg-enable-gcc-optzns
 fails to link induct.f90
In-Reply-To: <bug-9692-206@http.llvm.org/bugs/>
References: <bug-9692-206@http.llvm.org/bugs/>
Message-ID: <20110525214545.4A0202A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9692

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #14 from Duncan Sands <baldrick at free.fr> 2011-05-25 16:45:43 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110523/121435.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 May 25 18:26:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 18:26:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9998] likely wrong code bug
In-Reply-To: <bug-9998-206@http.llvm.org/bugs/>
References: <bug-9998-206@http.llvm.org/bugs/>
Message-ID: <20110525232638.7615D2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9998

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-05-25 18:26:38 CDT ---
r132097.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 18:48:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 18:48:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8868] Mips code generator fails during live
	interval analysis
In-Reply-To: <bug-8868-206@http.llvm.org/bugs/>
References: <bug-8868-206@http.llvm.org/bugs/>
Message-ID: <20110525234809.24C572A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8868

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Bruno Cardoso Lopes <bruno.cardoso at gmail.com> 2011-05-25 18:48:08 CDT ---
Hi,

Akira fixed this in r132076
http://llvm.org/viewvc/llvm-project?rev=132076&view=rev

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 20:08:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 20:08:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10014] New: vect_var_.957_3273 =
 [vec_unpack_float_lo_expr] vect_var_.955_3272
Message-ID: <bug-10014-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10014

           Summary: vect_var_.957_3273 = [vec_unpack_float_lo_expr]
                    vect_var_.955_3272
           Product: dragonegg
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


With dragon egg svn at r132085, the fatigue.f90 ICEs the gcc 4.5.3 compiler
when compiled with...


[MacPro:pb05/lin/source] howarth% /sw/lib/gcc4.5/bin/gfortran
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -msse3 -O3
-fplugin-arg-dragonegg-enable-gcc-optzns fatigue.f90 -o fatigue    
vect_var_.957_3273 = [vec_unpack_float_lo_expr] vect_var_.955_3272;

*** 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
fatigue.f90: In function ?MAIN__?:
fatigue.f90:1265:0: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

backtraces as...


[MacPro:pb05/lin/source] howarth% gdb
/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951
...
(gdb) r fatigue.f90 -fPIC -quiet -dumpbase fatigue.f90
-mmacosx-version-min=10.7.0 -msse3 -mtune=generic -auxbase fatigue -O3 -version
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so
-fplugin-arg-dragonegg-enable-gcc-optzns -fintrinsic-modules-path
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o
/var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//ccqvG3k4.s
Starting program:
/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951 fatigue.f90
-fPIC -quiet -dumpbase fatigue.f90 -mmacosx-version-min=10.7.0 -msse3
-mtune=generic -auxbase fatigue -O3 -version
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so
-fplugin-arg-dragonegg-enable-gcc-optzns -fintrinsic-modules-path
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o
/var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//ccqvG3k4.s
...

vect_var_.957_3273 = [vec_unpack_float_lo_expr] vect_var_.955_3272;


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010
0x0000000142d888df in llvm::BasicBlock::getContext ()
(gdb) bt
#0  0x0000000142d888df in llvm::BasicBlock::getContext ()
#1  0x0000000142de4899 in llvm::BranchInst::BranchInst ()
#2  0x0000000142836512 in llvm::IRBuilder<true, llvm::TargetFolder,
llvm::IRBuilderDefaultInserter<true> >::CreateBr ()
#3  0x00007fff5fbfe020 in ?? ()
#4  0x0000000142833d9c in TreeToLLVM::EmitAssignRHS ()
#5  0x0000000142819417 in TreeToLLVM::RenderGIMPLE_ASSIGN ()
#6  0x00000001428154a2 in TreeToLLVM::EmitBasicBlock ()
#7  0x000000014281ad8b in TreeToLLVM::EmitFunction ()
#8  0x0000000142807e50 in emit_current_function ()
#9  0x00000001428039be in rtl_emit_function ()
#10 0x0000000100565382 in execute_one_pass (pass=0x142fbb088) at
../../gcc-4.5.3/gcc/passes.c:1568
#11 0x000000010056561d in execute_pass_list (pass=0x142fbb088) at
../../gcc-4.5.3/gcc/passes.c:1623
#12 0x00000001006595c1 in tree_rest_of_compilation (fndecl=0x141eb8a00) at
../../gcc-4.5.3/gcc/tree-optimize.c:413
#13 0x00000001007b4a83 in cgraph_expand_function (node=0x141ef5270) at
../../gcc-4.5.3/gcc/cgraphunit.c:1555
#14 0x00000001007b6cf4 in cgraph_optimize () at
../../gcc-4.5.3/gcc/cgraphunit.c:1634
#15 0x00000001007b71fd in cgraph_finalize_compilation_unit () at
../../gcc-4.5.3/gcc/cgraphunit.c:1103
#16 0x0000000100505db6 in write_global_declarations () at
../../gcc-4.5.3/gcc/langhooks.c:309
#17 0x000000010061224e in toplev_main (argc=19, argv=0x7fff5fbfee78) at
../../gcc-4.5.3/gcc/toplev.c:1065
#18 0x0000000100001594 in start ()
(gdb)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 20:24:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 20:24:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10015] New: -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns ICEs compiler for rnflow.f90
Message-ID: <bug-10015-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10015

           Summary: -O3 -fplugin-arg-dragonegg-enable-gcc-optzns ICEs
                    compiler for rnflow.f90
           Product: dragonegg
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The rnflow.f90 benchmark still ICEs the FSF gcc 4.5.3 compiler with dragon egg
svn r132085 when compiled with -O3 -fplugin-arg-dragonegg-enable-gcc-optzns...


[MacPro:pb05/lin/source] howarth% gdb
/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951
...
(gdb) r rnflow.f90 -fPIC -quiet -dumpbase rnflow.f90
-mmacosx-version-min=10.7.0 -msse3 -mtune=generic -auxbase rnflow -O3 -version
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so
-fplugin-arg-dragonegg-enable-gcc-optzns -fintrinsic-modules-path
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o
/var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//cc9dCGYo.s
Starting program:
/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951 rnflow.f90
-fPIC -quiet -dumpbase rnflow.f90 -mmacosx-version-min=10.7.0 -msse3
-mtune=generic -auxbase rnflow -O3 -version
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so
-fplugin-arg-dragonegg-enable-gcc-optzns -fintrinsic-modules-path
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o
/var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//cc9dCGYo.s
...

Versions of loaded plugins:
 dragonegg: exported
vect_var_.8353_238 = vect_var_.8351_237 v>> 64;


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010
0x0000000142d888df in llvm::BasicBlock::getContext ()
(gdb) bt
#0  0x0000000142d888df in llvm::BasicBlock::getContext ()
#1  0x0000000142de4899 in llvm::BranchInst::BranchInst ()
#2  0x0000000142836512 in llvm::IRBuilder<true, llvm::TargetFolder,
llvm::IRBuilderDefaultInserter<true> >::CreateBr ()
#3  0x00007fff5fbfe020 in ?? ()
#4  0x0000000142833d9c in TreeToLLVM::EmitAssignRHS ()
#5  0x0000000142819417 in TreeToLLVM::RenderGIMPLE_ASSIGN ()
#6  0x00000001428154a2 in TreeToLLVM::EmitBasicBlock ()
#7  0x000000014281ad8b in TreeToLLVM::EmitFunction ()
#8  0x0000000142807e50 in emit_current_function ()
#9  0x00000001428039be in rtl_emit_function ()
#10 0x0000000100565382 in execute_one_pass (pass=0x142fbb088) at
../../gcc-4.5.3/gcc/passes.c:1568
#11 0x000000010056561d in execute_pass_list (pass=0x142fbb088) at
../../gcc-4.5.3/gcc/passes.c:1623
#12 0x00000001006595c1 in tree_rest_of_compilation (fndecl=0x143525f00) at
../../gcc-4.5.3/gcc/tree-optimize.c:413
#13 0x00000001007b4a83 in cgraph_expand_function (node=0x141f35ea0) at
../../gcc-4.5.3/gcc/cgraphunit.c:1555
#14 0x00000001007b6cf4 in cgraph_optimize () at
../../gcc-4.5.3/gcc/cgraphunit.c:1634
#15 0x00000001007b71fd in cgraph_finalize_compilation_unit () at
../../gcc-4.5.3/gcc/cgraphunit.c:1103
#16 0x0000000100505db6 in write_global_declarations () at
../../gcc-4.5.3/gcc/langhooks.c:309
#17 0x000000010061224e in toplev_main (argc=19, argv=0x7fff5fbfee78) at
../../gcc-4.5.3/gcc/toplev.c:1065
#18 0x0000000100001594 in start ()
(gdb) 

This is for x86_64 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  Wed May 25 20:33:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 20:33:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10016] New: Missing line in OCaml Kaleidoscope
	tutorial
Message-ID: <bug-10016-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10016

           Summary: Missing line in OCaml Kaleidoscope tutorial
           Product: Website
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: damien.schoof at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I've just been working through the Kaleidoscope tutorial online at
http://llvm.org/docs/tutorial/OCamlLangImpl2.html#parserbinops and I've found a
missing line in the section about parsing binary operators (linked).
The line of code (along with the corresponding comment) is:

        (* Parse the primary expression after the binary operator. *)
        let rhs = parse_primary stream in

found in lines 63 and 64 of parser.ml.
This line is a very important part of the code, and it is impossible to
understand the flow of logic without them in the tutorial.  The tutorial
already mentions this line (below the relevant snippet) by saying "and then
parses the primary expression that follows."

All that is needed to fix this bug is to add the 2 lines of code in, and things
will make much more sense.
This bug applies only to the OCaml version of the tutorial, the C++ version is
fine.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 20:37:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 20:37:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10017] New: -ffast-math -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns ICEs on channel.f90
Message-ID: <bug-10017-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10017

           Summary: -ffast-math -O3
                    -fplugin-arg-dragonegg-enable-gcc-optzns ICEs on
                    channel.f90
           Product: dragonegg
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The channel.f90 Polyhedron 2005 benchmark ICEs the FSF gcc 4.5.3 compiler with
the dragon egg svn r132085 plugin with -ffast-math -O3
-fplugin-arg-dragonegg-enable-gcc-optzns...

[MacPro:pb05/lin/source] howarth% gdb
/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951
...
(gdb) r channel.f90 -fPIC -quiet -dumpbase channel.f90
-mmacosx-version-min=10.7.0 -msse3 -mtune=generic -auxbase channel -O3 -version
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -ffast-math
-fplugin-arg-dragonegg-enable-gcc-optzns -fintrinsic-modules-path
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o
/var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//cccrvy4i.s
Starting program:
/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951 channel.f90
-fPIC -quiet -dumpbase channel.f90 -mmacosx-version-min=10.7.0 -msse3
-mtune=generic -auxbase channel -O3 -version
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -ffast-math
-fplugin-arg-dragonegg-enable-gcc-optzns -fintrinsic-modules-path
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o
/var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//cccrvy4i.s
...

Versions of loaded plugins:
 dragonegg: exported

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000028
0x000000014297fa6e in llvm::DAGTypeLegalizer::ScalarizeVectorResult ()
(gdb) bt
#0  0x000000014297fa6e in llvm::DAGTypeLegalizer::ScalarizeVectorResult ()
#1  0x0000000142973c3f in llvm::DAGTypeLegalizer::run ()
#2  0x00000001429780b2 in llvm::SelectionDAG::LegalizeTypes ()
#3  0x0000000142a08744 in llvm::SelectionDAGISel::CodeGenAndEmitDAG ()
#4  0x0000000142a08540 in llvm::SelectionDAGISel::SelectAllBasicBlocks ()
#5  0x0000000142a07147 in llvm::SelectionDAGISel::runOnMachineFunction ()
#6  0x0000000142abaf1e in llvm::MachineFunctionPass::runOnFunction ()
#7  0x0000000142e07ed1 in llvm::FPPassManager::runOnFunction ()
#8  0x0000000142e0785b in llvm::FunctionPassManagerImpl::run ()
#9  0x0000000142e07715 in llvm::FunctionPassManager::run ()
#10 0x0000000142804ccc in llvm_finish_unit ()
#11 0x000000010056672d in invoke_plugin_callbacks (event=<value temporarily
unavailable, due to optimizations>, gcc_data=0x0) at
../../gcc-4.5.3/gcc/plugin.c:510
#12 0x0000000100612301 in toplev_main (argc=20, argv=0x7fff5fbfee60) at
../../gcc-4.5.3/gcc/toplev.c:1146
#13 0x0000000100001594 in start ()
(gdb)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 20:42:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 20:42:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10018] New: -ffast-math -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns ICEs on doduc.f90
Message-ID: <bug-10018-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10018

           Summary: -ffast-math -O3
                    -fplugin-arg-dragonegg-enable-gcc-optzns ICEs on
                    doduc.f90
           Product: dragonegg
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The doduc.f90 Polyhedron 2005 benchmark ICEs the FSF gcc 4.5.3 compiler with
dragon egg svn r132085 when using -ffast-math -O3
-fplugin-arg-dragonegg-enable-gcc-optzns...

[MacPro:pb05/lin/source] howarth% de-gfortran45 -msse3 -ffast-math -O3
-fplugin-arg-dragonegg-enable-gcc-optzns doduc.f90 -o doduc
 <vec_cond_expr 0x147061240
    type <vector_type 0x144694d20
        type <real_type 0x1446480a8 real(kind=8) DF
            size <integer_cst 0x14462ba50 constant 64>
            unit size <integer_cst 0x14462ba78 constant 8>
            align 64 symtab 0 alias set 2 canonical type 0x1446480a8 precision
64
            pointer_to_this <pointer_type 0x1446482a0> reference_to_this
<reference_type 0x14525e0a8>>
        V2DF
        size <integer_cst 0x14462bc58 constant 128>
        unit size <integer_cst 0x14462bc80 constant 16>
        align 128 symtab 0 alias set 2 canonical type 0x144694d20 nunits 2
        pointer_to_this <pointer_type 0x14469e930>>

    arg 0 <ge_expr 0x147066e38 type <vector_type 0x144694d20>

        arg 0 <ssa_name 0x1470722c0 type <vector_type 0x144694d20>
            var <var_decl 0x14706fbe0 vect_var_.2045>def_stmt
vect_var_.2045_3878 = ABS_EXPR <vect_var_.2038_3872>;

            version 3878>
        arg 1 <ssa_name 0x147072268 type <vector_type 0x144694d20>
            var <var_decl 0x14706faa0 vect_var_.2043>def_stmt
vect_var_.2043_3877 = MAX_EXPR <vect_var_.2041_3875, {
9.99999977648258209228515625e-3, 9.99999977648258209228515625e-3 }>;

            version 3877>>
    arg 1 <ssa_name 0x147072420 type <vector_type 0x144694d20>
        var <var_decl 0x14706fd20 vect_var_.2047>def_stmt vect_var_.2047_3880 =
vect_var_.2046_3879 / vect_var_.2045_3878;

        version 3880>
    arg 2 <ssa_name 0x147072000 type <vector_type 0x144694d20>
        var <var_decl 0x14706f780 vect_var_.2038>def_stmt vect_var_.2038_3872 =
vect_var_.2036_3869 * vect_cst_.2039_3871;

        version 3872>>
*** 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
doduc.f90: In function ?s00017_?:
doduc.f90:1480:0: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This backtraces as...

[MacPro:pb05/lin/source] howarth% gdb
/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951
...

(gdb) r doduc.f90 -fPIC -quiet -dumpbase doduc.f90 -mmacosx-version-min=10.7.0
-msse3 -mtune=generic -auxbase doduc -O3 -version
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -ffast-math
-fplugin-arg-dragonegg-enable-gcc-optzns -fintrinsic-modules-path
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o
/var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//ccW45aQF.s
Starting program:
/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.3/f951 doduc.f90 -fPIC
-quiet -dumpbase doduc.f90 -mmacosx-version-min=10.7.0 -msse3 -mtune=generic
-auxbase doduc -O3 -version -fplugin=/sw/lib/gcc4.5/lib/dragonegg.so
-ffast-math -fplugin-arg-dragonegg-enable-gcc-optzns -fintrinsic-modules-path
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin11.0.0/4.5.3/finclude -o
/var/folders/0k/n67sywk41kz5jjys5nv6mnpg++++fp/T//ccW45aQF.s
...

Versions of loaded plugins:
 dragonegg: exported
 <vec_cond_expr 0x145ec9240
    type <vector_type 0x141d6ad20
        type <real_type 0x141d1e0a8 real(kind=8) DF
            size <integer_cst 0x141d01a50 constant 64>
            unit size <integer_cst 0x141d01a78 constant 8>
            align 64 symtab 0 alias set 2 canonical type 0x141d1e0a8 precision
64
            pointer_to_this <pointer_type 0x141d1e2a0> reference_to_this
<reference_type 0x14322c0a8>>
        V2DF
        size <integer_cst 0x141d01c58 constant 128>
        unit size <integer_cst 0x141d01c80 constant 16>
        align 128 symtab 0 alias set 2 canonical type 0x141d6ad20 nunits 2
        pointer_to_this <pointer_type 0x141d74930>>

    arg 0 <ge_expr 0x145ecee38 type <vector_type 0x141d6ad20>

        arg 0 <ssa_name 0x145eda2c0 type <vector_type 0x141d6ad20>
            var <var_decl 0x145ed7be0 vect_var_.2045>def_stmt
vect_var_.2045_3878 = ABS_EXPR <vect_var_.2038_3872>;

            version 3878>
        arg 1 <ssa_name 0x145eda268 type <vector_type 0x141d6ad20>
            var <var_decl 0x145ed7aa0 vect_var_.2043>def_stmt
vect_var_.2043_3877 = MAX_EXPR <vect_var_.2041_3875, {
9.99999977648258209228515625e-3, 9.99999977648258209228515625e-3 }>;

            version 3877>>
    arg 1 <ssa_name 0x145eda420 type <vector_type 0x141d6ad20>
        var <var_decl 0x145ed7d20 vect_var_.2047>def_stmt vect_var_.2047_3880 =
vect_var_.2046_3879 / vect_var_.2045_3878;

        version 3880>
    arg 2 <ssa_name 0x145eda000 type <vector_type 0x141d6ad20>
        var <var_decl 0x145ed7780 vect_var_.2038>def_stmt vect_var_.2038_3872 =
vect_var_.2036_3869 * vect_cst_.2039_3871;

        version 3872>>

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000000a
0x000000014280f044 in llvm::DenseMap<llvm::Constant*, llvm::GlobalVariable*,
llvm::DenseMapInfo<llvm::Constant*>, llvm::DenseMapInfo<llvm::GlobalVariable*>
>::~DenseMap ()
(gdb) bt
#0  0x000000014280f044 in llvm::DenseMap<llvm::Constant*,
llvm::GlobalVariable*, llvm::DenseMapInfo<llvm::Constant*>,
llvm::DenseMapInfo<llvm::GlobalVariable*> >::~DenseMap ()
#1  0x00007fff5fbfdf40 in ?? ()
#2  0x000000014282cb95 in TreeToLLVM::EmitRegisterConstant ()
#3  0x00000001428348e2 in TreeToLLVM::EmitAssignSingleRHS ()
#4  0x0000000142833c84 in TreeToLLVM::EmitAssignRHS ()
#5  0x0000000142819417 in TreeToLLVM::RenderGIMPLE_ASSIGN ()
#6  0x00000001428154a2 in TreeToLLVM::EmitBasicBlock ()
#7  0x000000014281ad8b in TreeToLLVM::EmitFunction ()
#8  0x0000000142807e50 in emit_current_function ()
#9  0x00000001428039be in rtl_emit_function ()
#10 0x0000000100565382 in execute_one_pass (pass=0x142fbb088) at
../../gcc-4.5.3/gcc/passes.c:1568
#11 0x000000010056561d in execute_pass_list (pass=0x142fbb088) at
../../gcc-4.5.3/gcc/passes.c:1623
#12 0x00000001006595c1 in tree_rest_of_compilation (fndecl=0x14368c400) at
../../gcc-4.5.3/gcc/tree-optimize.c:413
#13 0x00000001007b4a83 in cgraph_expand_function (node=0x143262888) at
../../gcc-4.5.3/gcc/cgraphunit.c:1555
#14 0x00000001007b6cf4 in cgraph_optimize () at
../../gcc-4.5.3/gcc/cgraphunit.c:1634
#15 0x00000001007b71fd in cgraph_finalize_compilation_unit () at
../../gcc-4.5.3/gcc/cgraphunit.c:1103
#16 0x0000000100505db6 in write_global_declarations () at
../../gcc-4.5.3/gcc/langhooks.c:309
#17 0x000000010061224e in toplev_main (argc=20, argv=0x7fff5fbfee68) at
../../gcc-4.5.3/gcc/toplev.c:1065
#18 0x0000000100001594 in start ()
(gdb)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 22:14:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 22:14:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10019] New: -ffast-math -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns LLVM ERRORs on induct.f90
Message-ID: <bug-10019-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10019

           Summary: -ffast-math -O3
                    -fplugin-arg-dragonegg-enable-gcc-optzns LLVM ERRORs
                    on induct.f90
           Product: dragonegg
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The induct.f90 Polyhedron 2005 benchmark produces a LLVM ERROR when compiled
with -ffast-math -O3 -fplugin-arg-dragonegg-enable-gcc-optzns on x86_64 darwin
as follows...

[MacPro:pb05/lin/source] howarth% de-gfortran45  -ffast-math -O3
-fplugin-arg-dragonegg-enable-gcc-optzns induct.f90 -o induct
LLVM ERROR: Cannot select: 0x7f8ff315ea10: f64 = add 0x7f8ff3183010,
0x7f8ff31db510 [ID=169]
  0x7f8ff3183010: f64 = extract_vector_elt 0x7f8ff31d3210, 0x7f8ff320c210
[ID=166]
    0x7f8ff31d3210: v2f64 = X86ISD::UNPCKHPD 0x7f8ff31dad10, 0x7f8ff31dad10
[ID=163]
      0x7f8ff31dad10: v2f64 = fadd 0x7f8ff31d3010, 0x7f8ff3181010 [ORD=2700]
[ID=162]
        0x7f8ff31d3010: v2f64 = fadd 0x7f8ff315ee10, 0x7f8ff31d4610 [ORD=2688]
[ID=161]
          0x7f8ff315ee10: v2f64 = fdiv 0x7f8ff329f510, 0x7f8ff329ee10
[ORD=2687] [ID=156]
            0x7f8ff329f510: v2f64 = fmul 0x7f8ff31d2910, 0x7f8ff3278810
[ORD=2677] [ID=106]
              0x7f8ff31d2910: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff32a0510 [ORD=2677] [ID=64]
                0x7f8ff32a0510: v2f64 = Register %vreg79 [ORD=2677] [ID=22]
              0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
                0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                  0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]


                0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                  0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]


                0x7f8ff3278b10: i8 = Constant<0> [ID=45]
            0x7f8ff329ee10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff3382f10 [ORD=2686] [ID=152]
              0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
              0x7f8ff3382f10: v2f64 = fadd 0x7f8ff3110410, 0x7f8ff3278c10
[ORD=2685] [ID=147]
                0x7f8ff3110410: v2f64 = fadd 0x7f8ff3116810, 0x7f8ff3193e10
[ORD=2682] [ID=142]
                  0x7f8ff3116810: v2f64 = fmul 0x7f8ff329f710, 0x7f8ff329f710
[ORD=2681] [ID=133]


                  0x7f8ff3193e10: v2f64 = fmul 0x7f8ff310f210, 0x7f8ff310f210
[ORD=2679] [ID=137]


                0x7f8ff3278c10: v2f64 = fmul 0x7f8ff3110710, 0x7f8ff3110710
[ORD=2684] [ID=129]
                  0x7f8ff3110710: v2f64 = fadd 0x7f8ff3279310, 0x7f8ff3110010
[ORD=2683] [ID=116]


                  0x7f8ff3110710: v2f64 = fadd 0x7f8ff3279310, 0x7f8ff3110010
[ORD=2683] [ID=116]


          0x7f8ff31d4610: v2f64 = fadd 0x7f8ff31d7f10, 0x7f8ff3193210
[ORD=2676] [ID=160]
            0x7f8ff31d7f10: v2f64 = fadd 0x7f8ff3110910, 0x7f8ff3243c10
[ORD=2664] [ID=159]
              0x7f8ff3110910: v2f64 = fdiv 0x7f8ff31d6d10, 0x7f8ff31d2a10
[ORD=2663] [ID=158]
                0x7f8ff31d6d10: v2f64 = fmul 0x7f8ff3193f10, 0x7f8ff3278810
[ORD=2653] [ID=108]
                  0x7f8ff3193f10: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff310ff10 [ORD=2653] [ID=56]

                  0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]



                0x7f8ff31d2a10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff3207310 [ORD=2662] [ID=154]
                  0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
                  0x7f8ff3207310: v2f64 = fadd 0x7f8ff3344f10, 0x7f8ff3207610
[ORD=2661] [ID=149]


              0x7f8ff3243c10: v2f64 = bitcast 0x7f8ff32a0910 [ID=83]
                0x7f8ff32a0910: v4i32 = BUILD_VECTOR 0x7f8ff3346210,
0x7f8ff3346210, 0x7f8ff3346210, 0x7f8ff3346210 [ID=79]
                  0x7f8ff3346210: i32 = TargetConstant<0> [ID=43]
                  0x7f8ff3346210: i32 = TargetConstant<0> [ID=43]
                  0x7f8ff3346210: i32 = TargetConstant<0> [ID=43]
                  0x7f8ff3346210: i32 = TargetConstant<0> [ID=43]
            0x7f8ff3193210: v2f64 = fdiv 0x7f8ff3243d10, 0x7f8ff3182710
[ORD=2675] [ID=157]
              0x7f8ff3243d10: v2f64 = fmul 0x7f8ff3243f10, 0x7f8ff3278810
[ORD=2665] [ID=107]
                0x7f8ff3243f10: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3244010 [ORD=2665] [ID=60]
                  0x7f8ff3244010: v2f64 = Register %vreg75 [ORD=2665] [ID=18]
                0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
                  0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310
[ID=93]

                  0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310
[ID=93]

                  0x7f8ff3278b10: i8 = Constant<0> [ID=45]
              0x7f8ff3182710: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff31d6810 [ORD=2674] [ID=153]
                0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
                0x7f8ff31d6810: v2f64 = fadd 0x7f8ff3116a10, 0x7f8ff31dac10
[ORD=2673] [ID=148]
                  0x7f8ff3116a10: v2f64 = fadd 0x7f8ff315f010, 0x7f8ff31d8410
[ORD=2670] [ID=143]


                  0x7f8ff31dac10: v2f64 = fmul 0x7f8ff310fc10, 0x7f8ff310fc10
[ORD=2672] [ID=130]


        0x7f8ff3181010: v2f64 = fdiv 0x7f8ff31d4b10, 0x7f8ff320bf10 [ORD=2699]
[ID=155]
          0x7f8ff31d4b10: v2f64 = fmul 0x7f8ff31d5810, 0x7f8ff3278810
[ORD=2689] [ID=105]
            0x7f8ff31d5810: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff31d7810 [ORD=2689] [ID=68]
              0x7f8ff31d7810: v2f64 = Register %vreg83 [ORD=2689] [ID=26]
            0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
              0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]
                  0x7f8ff310f110: f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3182110 [ORD=2644] [ID=55]

                  0x7f8ff31d4a10: f64,ch = load 0x7f8ff42ad5b8, 0x7f8ff329ff10,
0x7f8ff31d8010<LD8[%uglygep103104]> [ORD=2643] [ID=87]


              0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]
                  0x7f8ff310f110: f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3182110 [ORD=2644] [ID=55]

                  0x7f8ff31d4a10: f64,ch = load 0x7f8ff42ad5b8, 0x7f8ff329ff10,
0x7f8ff31d8010<LD8[%uglygep103104]> [ORD=2643] [ID=87]


              0x7f8ff3278b10: i8 = Constant<0> [ID=45]
          0x7f8ff320bf10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff31d4910 [ORD=2698] [ID=151]
            0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
            0x7f8ff31d4910: v2f64 = fadd 0x7f8ff329f210, 0x7f8ff3116910
[ORD=2697] [ID=146]
              0x7f8ff329f210: v2f64 = fadd 0x7f8ff3110110, 0x7f8ff3193410
[ORD=2694] [ID=141]
                0x7f8ff3110110: v2f64 = fmul 0x7f8ff31d6a10, 0x7f8ff31d6a10
[ORD=2693] [ID=132]
                  0x7f8ff31d6a10: v2f64 = fadd 0x7f8ff31d8110, 0x7f8ff3182a10
[ORD=2692] [ID=119]


                  0x7f8ff31d6a10: v2f64 = fadd 0x7f8ff31d8110, 0x7f8ff3182a10
[ORD=2692] [ID=119]


                0x7f8ff3193410: v2f64 = fmul 0x7f8ff31d5010, 0x7f8ff31d5010
[ORD=2691] [ID=136]
                  0x7f8ff31d5010: v2f64 = fadd 0x7f8ff32a0310, 0x7f8ff31d3110
[ORD=2690] [ID=123]


                  0x7f8ff31d5010: v2f64 = fadd 0x7f8ff32a0310, 0x7f8ff31d3110
[ORD=2690] [ID=123]


              0x7f8ff3116910: v2f64 = fmul 0x7f8ff310f510, 0x7f8ff310f510
[ORD=2696] [ID=128]
                0x7f8ff310f510: v2f64 = fadd 0x7f8ff31d4710, 0x7f8ff3110010
[ORD=2695] [ID=115]
                  0x7f8ff31d4710: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3206e10 [ORD=2695] [ID=71]

                  0x7f8ff3110010: v2f64 = X86ISD::SHUFPD 0x7f8ff3110610,
0x7f8ff3110610, 0x7f8ff3278b10 [ID=109]



                0x7f8ff310f510: v2f64 = fadd 0x7f8ff31d4710, 0x7f8ff3110010
[ORD=2695] [ID=115]
                  0x7f8ff31d4710: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3206e10 [ORD=2695] [ID=71]

                  0x7f8ff3110010: v2f64 = X86ISD::SHUFPD 0x7f8ff3110610,
0x7f8ff3110610, 0x7f8ff3278b10 [ID=109]



      0x7f8ff31dad10: v2f64 = fadd 0x7f8ff31d3010, 0x7f8ff3181010 [ORD=2700]
[ID=162]
        0x7f8ff31d3010: v2f64 = fadd 0x7f8ff315ee10, 0x7f8ff31d4610 [ORD=2688]
[ID=161]
          0x7f8ff315ee10: v2f64 = fdiv 0x7f8ff329f510, 0x7f8ff329ee10
[ORD=2687] [ID=156]
            0x7f8ff329f510: v2f64 = fmul 0x7f8ff31d2910, 0x7f8ff3278810
[ORD=2677] [ID=106]
              0x7f8ff31d2910: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff32a0510 [ORD=2677] [ID=64]
                0x7f8ff32a0510: v2f64 = Register %vreg79 [ORD=2677] [ID=22]
              0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
                0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                  0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]


                0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                  0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]


                0x7f8ff3278b10: i8 = Constant<0> [ID=45]
            0x7f8ff329ee10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff3382f10 [ORD=2686] [ID=152]
              0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
              0x7f8ff3382f10: v2f64 = fadd 0x7f8ff3110410, 0x7f8ff3278c10
[ORD=2685] [ID=147]
                0x7f8ff3110410: v2f64 = fadd 0x7f8ff3116810, 0x7f8ff3193e10
[ORD=2682] [ID=142]
                  0x7f8ff3116810: v2f64 = fmul 0x7f8ff329f710, 0x7f8ff329f710
[ORD=2681] [ID=133]


                  0x7f8ff3193e10: v2f64 = fmul 0x7f8ff310f210, 0x7f8ff310f210
[ORD=2679] [ID=137]


                0x7f8ff3278c10: v2f64 = fmul 0x7f8ff3110710, 0x7f8ff3110710
[ORD=2684] [ID=129]
                  0x7f8ff3110710: v2f64 = fadd 0x7f8ff3279310, 0x7f8ff3110010
[ORD=2683] [ID=116]


                  0x7f8ff3110710: v2f64 = fadd 0x7f8ff3279310, 0x7f8ff3110010
[ORD=2683] [ID=116]


          0x7f8ff31d4610: v2f64 = fadd 0x7f8ff31d7f10, 0x7f8ff3193210
[ORD=2676] [ID=160]
            0x7f8ff31d7f10: v2f64 = fadd 0x7f8ff3110910, 0x7f8ff3243c10
[ORD=2664] [ID=159]
              0x7f8ff3110910: v2f64 = fdiv 0x7f8ff31d6d10, 0x7f8ff31d2a10
[ORD=2663] [ID=158]
                0x7f8ff31d6d10: v2f64 = fmul 0x7f8ff3193f10, 0x7f8ff3278810
[ORD=2653] [ID=108]
                  0x7f8ff3193f10: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff310ff10 [ORD=2653] [ID=56]

                  0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]



                0x7f8ff31d2a10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff3207310 [ORD=2662] [ID=154]
                  0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
                  0x7f8ff3207310: v2f64 = fadd 0x7f8ff3344f10, 0x7f8ff3207610
[ORD=2661] [ID=149]


              0x7f8ff3243c10: v2f64 = bitcast 0x7f8ff32a0910 [ID=83]
                0x7f8ff32a0910: v4i32 = BUILD_VECTOR 0x7f8ff3346210,
0x7f8ff3346210, 0x7f8ff3346210, 0x7f8ff3346210 [ID=79]
                  0x7f8ff3346210: i32 = TargetConstant<0> [ID=43]
                  0x7f8ff3346210: i32 = TargetConstant<0> [ID=43]
                  0x7f8ff3346210: i32 = TargetConstant<0> [ID=43]
                  0x7f8ff3346210: i32 = TargetConstant<0> [ID=43]
            0x7f8ff3193210: v2f64 = fdiv 0x7f8ff3243d10, 0x7f8ff3182710
[ORD=2675] [ID=157]
              0x7f8ff3243d10: v2f64 = fmul 0x7f8ff3243f10, 0x7f8ff3278810
[ORD=2665] [ID=107]
                0x7f8ff3243f10: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3244010 [ORD=2665] [ID=60]
                  0x7f8ff3244010: v2f64 = Register %vreg75 [ORD=2665] [ID=18]
                0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
                  0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310
[ID=93]

                  0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310
[ID=93]

                  0x7f8ff3278b10: i8 = Constant<0> [ID=45]
              0x7f8ff3182710: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff31d6810 [ORD=2674] [ID=153]
                0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
                0x7f8ff31d6810: v2f64 = fadd 0x7f8ff3116a10, 0x7f8ff31dac10
[ORD=2673] [ID=148]
                  0x7f8ff3116a10: v2f64 = fadd 0x7f8ff315f010, 0x7f8ff31d8410
[ORD=2670] [ID=143]


                  0x7f8ff31dac10: v2f64 = fmul 0x7f8ff310fc10, 0x7f8ff310fc10
[ORD=2672] [ID=130]


        0x7f8ff3181010: v2f64 = fdiv 0x7f8ff31d4b10, 0x7f8ff320bf10 [ORD=2699]
[ID=155]
          0x7f8ff31d4b10: v2f64 = fmul 0x7f8ff31d5810, 0x7f8ff3278810
[ORD=2689] [ID=105]
            0x7f8ff31d5810: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff31d7810 [ORD=2689] [ID=68]
              0x7f8ff31d7810: v2f64 = Register %vreg83 [ORD=2689] [ID=26]
            0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
              0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]
                  0x7f8ff310f110: f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3182110 [ORD=2644] [ID=55]

                  0x7f8ff31d4a10: f64,ch = load 0x7f8ff42ad5b8, 0x7f8ff329ff10,
0x7f8ff31d8010<LD8[%uglygep103104]> [ORD=2643] [ID=87]


              0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]
                  0x7f8ff310f110: f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3182110 [ORD=2644] [ID=55]

                  0x7f8ff31d4a10: f64,ch = load 0x7f8ff42ad5b8, 0x7f8ff329ff10,
0x7f8ff31d8010<LD8[%uglygep103104]> [ORD=2643] [ID=87]


              0x7f8ff3278b10: i8 = Constant<0> [ID=45]
          0x7f8ff320bf10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff31d4910 [ORD=2698] [ID=151]
            0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
            0x7f8ff31d4910: v2f64 = fadd 0x7f8ff329f210, 0x7f8ff3116910
[ORD=2697] [ID=146]
              0x7f8ff329f210: v2f64 = fadd 0x7f8ff3110110, 0x7f8ff3193410
[ORD=2694] [ID=141]
                0x7f8ff3110110: v2f64 = fmul 0x7f8ff31d6a10, 0x7f8ff31d6a10
[ORD=2693] [ID=132]
                  0x7f8ff31d6a10: v2f64 = fadd 0x7f8ff31d8110, 0x7f8ff3182a10
[ORD=2692] [ID=119]


                  0x7f8ff31d6a10: v2f64 = fadd 0x7f8ff31d8110, 0x7f8ff3182a10
[ORD=2692] [ID=119]


                0x7f8ff3193410: v2f64 = fmul 0x7f8ff31d5010, 0x7f8ff31d5010
[ORD=2691] [ID=136]
                  0x7f8ff31d5010: v2f64 = fadd 0x7f8ff32a0310, 0x7f8ff31d3110
[ORD=2690] [ID=123]


                  0x7f8ff31d5010: v2f64 = fadd 0x7f8ff32a0310, 0x7f8ff31d3110
[ORD=2690] [ID=123]


              0x7f8ff3116910: v2f64 = fmul 0x7f8ff310f510, 0x7f8ff310f510
[ORD=2696] [ID=128]
                0x7f8ff310f510: v2f64 = fadd 0x7f8ff31d4710, 0x7f8ff3110010
[ORD=2695] [ID=115]
                  0x7f8ff31d4710: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3206e10 [ORD=2695] [ID=71]

                  0x7f8ff3110010: v2f64 = X86ISD::SHUFPD 0x7f8ff3110610,
0x7f8ff3110610, 0x7f8ff3278b10 [ID=109]



                0x7f8ff310f510: v2f64 = fadd 0x7f8ff31d4710, 0x7f8ff3110010
[ORD=2695] [ID=115]
                  0x7f8ff31d4710: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3206e10 [ORD=2695] [ID=71]

                  0x7f8ff3110010: v2f64 = X86ISD::SHUFPD 0x7f8ff3110610,
0x7f8ff3110610, 0x7f8ff3278b10 [ID=109]



    0x7f8ff320c210: i64 = Constant<0> [ORD=2645] [ID=2]
  0x7f8ff31db510: f64 = extract_vector_elt 0x7f8ff31db210, 0x7f8ff320c210
[ID=167]
    0x7f8ff31db210: v2f64 = vector_shuffle 0x7f8ff31d3210, 0x7f8ff31d4310<1,u>
[ID=165]
      0x7f8ff31d3210: v2f64 = X86ISD::UNPCKHPD 0x7f8ff31dad10, 0x7f8ff31dad10
[ID=163]
        0x7f8ff31dad10: v2f64 = fadd 0x7f8ff31d3010, 0x7f8ff3181010 [ORD=2700]
[ID=162]
          0x7f8ff31d3010: v2f64 = fadd 0x7f8ff315ee10, 0x7f8ff31d4610
[ORD=2688] [ID=161]
            0x7f8ff315ee10: v2f64 = fdiv 0x7f8ff329f510, 0x7f8ff329ee10
[ORD=2687] [ID=156]
              0x7f8ff329f510: v2f64 = fmul 0x7f8ff31d2910, 0x7f8ff3278810
[ORD=2677] [ID=106]
                0x7f8ff31d2910: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff32a0510 [ORD=2677] [ID=64]
                  0x7f8ff32a0510: v2f64 = Register %vreg79 [ORD=2677] [ID=22]
                0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
                  0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310
[ID=93]

                  0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310
[ID=93]

                  0x7f8ff3278b10: i8 = Constant<0> [ID=45]
              0x7f8ff329ee10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff3382f10 [ORD=2686] [ID=152]
                0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
                0x7f8ff3382f10: v2f64 = fadd 0x7f8ff3110410, 0x7f8ff3278c10
[ORD=2685] [ID=147]
                  0x7f8ff3110410: v2f64 = fadd 0x7f8ff3116810, 0x7f8ff3193e10
[ORD=2682] [ID=142]


                  0x7f8ff3278c10: v2f64 = fmul 0x7f8ff3110710, 0x7f8ff3110710
[ORD=2684] [ID=129]


            0x7f8ff31d4610: v2f64 = fadd 0x7f8ff31d7f10, 0x7f8ff3193210
[ORD=2676] [ID=160]
              0x7f8ff31d7f10: v2f64 = fadd 0x7f8ff3110910, 0x7f8ff3243c10
[ORD=2664] [ID=159]
                0x7f8ff3110910: v2f64 = fdiv 0x7f8ff31d6d10, 0x7f8ff31d2a10
[ORD=2663] [ID=158]
                  0x7f8ff31d6d10: v2f64 = fmul 0x7f8ff3193f10, 0x7f8ff3278810
[ORD=2653] [ID=108]


                  0x7f8ff31d2a10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff3207310 [ORD=2662] [ID=154]


                0x7f8ff3243c10: v2f64 = bitcast 0x7f8ff32a0910 [ID=83]
                  0x7f8ff32a0910: v4i32 = BUILD_VECTOR 0x7f8ff3346210,
0x7f8ff3346210, 0x7f8ff3346210, 0x7f8ff3346210 [ID=79]




              0x7f8ff3193210: v2f64 = fdiv 0x7f8ff3243d10, 0x7f8ff3182710
[ORD=2675] [ID=157]
                0x7f8ff3243d10: v2f64 = fmul 0x7f8ff3243f10, 0x7f8ff3278810
[ORD=2665] [ID=107]
                  0x7f8ff3243f10: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3244010 [ORD=2665] [ID=60]

                  0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]



                0x7f8ff3182710: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff31d6810 [ORD=2674] [ID=153]
                  0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
                  0x7f8ff31d6810: v2f64 = fadd 0x7f8ff3116a10, 0x7f8ff31dac10
[ORD=2673] [ID=148]


          0x7f8ff3181010: v2f64 = fdiv 0x7f8ff31d4b10, 0x7f8ff320bf10
[ORD=2699] [ID=155]
            0x7f8ff31d4b10: v2f64 = fmul 0x7f8ff31d5810, 0x7f8ff3278810
[ORD=2689] [ID=105]
              0x7f8ff31d5810: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff31d7810 [ORD=2689] [ID=68]
                0x7f8ff31d7810: v2f64 = Register %vreg83 [ORD=2689] [ID=26]
              0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
                0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                  0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]


                0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                  0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]


                0x7f8ff3278b10: i8 = Constant<0> [ID=45]
            0x7f8ff320bf10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff31d4910 [ORD=2698] [ID=151]
              0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
              0x7f8ff31d4910: v2f64 = fadd 0x7f8ff329f210, 0x7f8ff3116910
[ORD=2697] [ID=146]
                0x7f8ff329f210: v2f64 = fadd 0x7f8ff3110110, 0x7f8ff3193410
[ORD=2694] [ID=141]
                  0x7f8ff3110110: v2f64 = fmul 0x7f8ff31d6a10, 0x7f8ff31d6a10
[ORD=2693] [ID=132]


                  0x7f8ff3193410: v2f64 = fmul 0x7f8ff31d5010, 0x7f8ff31d5010
[ORD=2691] [ID=136]


                0x7f8ff3116910: v2f64 = fmul 0x7f8ff310f510, 0x7f8ff310f510
[ORD=2696] [ID=128]
                  0x7f8ff310f510: v2f64 = fadd 0x7f8ff31d4710, 0x7f8ff3110010
[ORD=2695] [ID=115]


                  0x7f8ff310f510: v2f64 = fadd 0x7f8ff31d4710, 0x7f8ff3110010
[ORD=2695] [ID=115]


        0x7f8ff31dad10: v2f64 = fadd 0x7f8ff31d3010, 0x7f8ff3181010 [ORD=2700]
[ID=162]
          0x7f8ff31d3010: v2f64 = fadd 0x7f8ff315ee10, 0x7f8ff31d4610
[ORD=2688] [ID=161]
            0x7f8ff315ee10: v2f64 = fdiv 0x7f8ff329f510, 0x7f8ff329ee10
[ORD=2687] [ID=156]
              0x7f8ff329f510: v2f64 = fmul 0x7f8ff31d2910, 0x7f8ff3278810
[ORD=2677] [ID=106]
                0x7f8ff31d2910: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff32a0510 [ORD=2677] [ID=64]
                  0x7f8ff32a0510: v2f64 = Register %vreg79 [ORD=2677] [ID=22]
                0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
                  0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310
[ID=93]

                  0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310
[ID=93]

                  0x7f8ff3278b10: i8 = Constant<0> [ID=45]
              0x7f8ff329ee10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff3382f10 [ORD=2686] [ID=152]
                0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
                0x7f8ff3382f10: v2f64 = fadd 0x7f8ff3110410, 0x7f8ff3278c10
[ORD=2685] [ID=147]
                  0x7f8ff3110410: v2f64 = fadd 0x7f8ff3116810, 0x7f8ff3193e10
[ORD=2682] [ID=142]


                  0x7f8ff3278c10: v2f64 = fmul 0x7f8ff3110710, 0x7f8ff3110710
[ORD=2684] [ID=129]


            0x7f8ff31d4610: v2f64 = fadd 0x7f8ff31d7f10, 0x7f8ff3193210
[ORD=2676] [ID=160]
              0x7f8ff31d7f10: v2f64 = fadd 0x7f8ff3110910, 0x7f8ff3243c10
[ORD=2664] [ID=159]
                0x7f8ff3110910: v2f64 = fdiv 0x7f8ff31d6d10, 0x7f8ff31d2a10
[ORD=2663] [ID=158]
                  0x7f8ff31d6d10: v2f64 = fmul 0x7f8ff3193f10, 0x7f8ff3278810
[ORD=2653] [ID=108]


                  0x7f8ff31d2a10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff3207310 [ORD=2662] [ID=154]


                0x7f8ff3243c10: v2f64 = bitcast 0x7f8ff32a0910 [ID=83]
                  0x7f8ff32a0910: v4i32 = BUILD_VECTOR 0x7f8ff3346210,
0x7f8ff3346210, 0x7f8ff3346210, 0x7f8ff3346210 [ID=79]




              0x7f8ff3193210: v2f64 = fdiv 0x7f8ff3243d10, 0x7f8ff3182710
[ORD=2675] [ID=157]
                0x7f8ff3243d10: v2f64 = fmul 0x7f8ff3243f10, 0x7f8ff3278810
[ORD=2665] [ID=107]
                  0x7f8ff3243f10: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff3244010 [ORD=2665] [ID=60]

                  0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]



                0x7f8ff3182710: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff31d6810 [ORD=2674] [ID=153]
                  0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
                  0x7f8ff31d6810: v2f64 = fadd 0x7f8ff3116a10, 0x7f8ff31dac10
[ORD=2673] [ID=148]


          0x7f8ff3181010: v2f64 = fdiv 0x7f8ff31d4b10, 0x7f8ff320bf10
[ORD=2699] [ID=155]
            0x7f8ff31d4b10: v2f64 = fmul 0x7f8ff31d5810, 0x7f8ff3278810
[ORD=2689] [ID=105]
              0x7f8ff31d5810: v2f64,ch = CopyFromReg 0x7f8ff42ad5b8,
0x7f8ff31d7810 [ORD=2689] [ID=68]
                0x7f8ff31d7810: v2f64 = Register %vreg83 [ORD=2689] [ID=26]
              0x7f8ff3278810: v2f64 = X86ISD::SHUFPD 0x7f8ff3382e10,
0x7f8ff3382e10, 0x7f8ff3278b10 [ID=98]
                0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                  0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]


                0x7f8ff3382e10: v2f64 = scalar_to_vector 0x7f8ff329f310 [ID=93]
                  0x7f8ff329f310: f64 = fmul 0x7f8ff310f110, 0x7f8ff31d4a10
[ORD=2644] [ID=89]


                0x7f8ff3278b10: i8 = Constant<0> [ID=45]
            0x7f8ff320bf10: v2f64 = llvm.x86.sse2.sqrt.pd 0x7f8ff310ee10,
0x7f8ff31d4910 [ORD=2698] [ID=151]
              0x7f8ff310ee10: i64 = Constant<761> [ORD=2662] [ID=17]
              0x7f8ff31d4910: v2f64 = fadd 0x7f8ff329f210, 0x7f8ff3116910
[ORD=2697] [ID=146]
                0x7f8ff329f210: v2f64 = fadd 0x7f8ff3110110, 0x7f8ff3193410
[ORD=2694] [ID=141]
                  0x7f8ff3110110: v2f64 = fmul 0x7f8ff31d6a10, 0x7f8ff31d6a10
[ORD=2693] [ID=132]


                  0x7f8ff3193410: v2f64 = fmul 0x7f8ff31d5010, 0x7f8ff31d5010
[ORD=2691] [ID=136]


                0x7f8ff3116910: v2f64 = fmul 0x7f8ff310f510, 0x7f8ff310f510
[ORD=2696] [ID=128]
                  0x7f8ff310f510: v2f64 = fadd 0x7f8ff31d4710, 0x7f8ff3110010
[ORD=2695] [ID=115]


                  0x7f8ff310f510: v2f64 = fadd 0x7f8ff31d4710, 0x7f8ff3110010
[ORD=2695] [ID=115]


      0x7f8ff31d4310: v2f64 = undef [ORD=2645] [ID=12]
    0x7f8ff320c210: i64 = Constant<0> [ORD=2645] [ID=2]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed May 25 22:48:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 25 May 2011 22:48:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10020] New: fail to codegen virtual function in
	template
Message-ID: <bug-10020-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10020

           Summary: fail to codegen virtual function in template
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6648)
 --> (http://llvm.org/bugs/attachment.cgi?id=6648)
testcase

The attached stand-alone program does passes Sema just fine, emits a .o but
fails to link when built with clang. It does link when built with gcc.

The problem is that we have a vtable with an undefined reference to 'GMG<DAR
const>::Accept(MV*) const'.

$ g++ x.cc -o x
$ clang++ x.cc -o x
/usr/bin/ld: /tmp/cc-rJc7RO.o: in function vtable for GMG<DAR
const>:x.cc(.rodata._ZTV3GMGIK3DARE+0x20): error: undefined reference to
'GMG<DAR const>::Accept(int) const'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu May 26 02:58:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 02:58:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10021] New: fatal error with AVX
Message-ID: <bug-10021-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10021

           Summary: fatal error with AVX
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: yottui at yahoo.co.jp
                CC: llvmbugs at cs.uiuc.edu


I would like to use __m128 and __m256.
However, the compilation fails with -mavx.

----- begin test case -----
#include <immintrin.h>

int main(int argc, char * argv[])
{
    __m128 v = _mm_set_ps(1, 2, 3, 4);

    return 0;
}
----- end of test case -----

----- begin output -----
$ clang++ -mavx -D _mm_malloc test.cpp
fatal error: error in backend: Cannot select: 0x2e17af8: v4f32 =
X86ISD::VUNPCKLPS 0x2e179e8, 0x2e17a70 [ID=42]
  0x2e179e8: v4f32 = X86ISD::VUNPCKLPS 0x2e170e0, 0x2e14f20 [ID=40]
    0x2e170e0: v4f32 = scalar_to_vector 0x2e17850 [ID=28]
      0x2e17850: f32,ch = load 0x2e3dca4, 0x2e17300,
0x2e146a0<LD4[ConstantPool]> [ID=26]
        0x2e17300: i32 = X86ISD::Wrapper 0x2e17278 [ID=24]
          0x2e17278: i32 = TargetConstantPool<float 4.000000e+00> 0 [ID=19]
        0x2e146a0: i32 = undef [ORD=1] [ID=3]
    0x2e14f20: v4f32 = scalar_to_vector 0x2e17058 [ID=37]
      0x2e17058: f32,ch = load 0x2e14e10, 0x2e148c0, 0x2e146a0<LD4[%2]>
[ORD=12] [ID=34]
        0x2e148c0: i32 = FrameIndex<1> [ORD=5] [ID=9]
        0x2e146a0: i32 = undef [ORD=1] [ID=3]
  0x2e17a70: v4f32 = X86ISD::VUNPCKLPS 0x2e17168, 0x2e14fa8 [ID=41]
    0x2e17168: v4f32 = scalar_to_vector 0x2e14e98 [ID=36]
      0x2e14e98: f32,ch = load 0x2e14e10, 0x2e14a58, 0x2e146a0<LD4[%3]>
[ORD=10] [ID=33]
        0x2e14a58: i32 = FrameIndex<2> [ORD=6] [ID=10]
        0x2e146a0: i32 = undef [ORD=1] [ID=3]
    0x2e14fa8: v4f32 = scalar_to_vector 0x2e171f0 [ID=38]
      0x2e171f0: f32,ch = load 0x2e14e10, 0x2e140c8, 0x2e146a0<LD4[%1]>
[ORD=14] [ID=35]
        0x2e140c8: i32 = FrameIndex<0> [ORD=4] [ID=8]
        0x2e146a0: i32 = undef [ORD=1] [ID=3]
----- end of output -----

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 07:38:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 07:38:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9725] Crash on ABS_EXPR with vector type
In-Reply-To: <bug-9725-206@http.llvm.org/bugs/>
References: <bug-9725-206@http.llvm.org/bugs/>
Message-ID: <20110526123824.895B72A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9725

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-05-26 07:38:24 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110523/121471.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 May 26 07:42:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 07:42:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10019] -ffast-math -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns LLVM ERRORs on induct.f90
In-Reply-To: <bug-10019-206@http.llvm.org/bugs/>
References: <bug-10019-206@http.llvm.org/bugs/>
Message-ID: <20110526124257.D0FE22A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10019

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Duncan Sands <baldrick at free.fr> 2011-05-26 07:42:57 CDT ---
These all compile now for me.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu May 26 08:04:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 08:04:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9972] clang make test...8 unexpected failures |
 CentOS5 GCC4.4.4
In-Reply-To: <bug-9972-206@http.llvm.org/bugs/>
References: <bug-9972-206@http.llvm.org/bugs/>
Message-ID: <20110526130450.7769C2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9972

apacherulzz at yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #6 from apacherulzz at yahoo.com 2011-05-26 08:04:49 CDT ---
:) That was it :)

I read over Takumi's instructions more careful and that was what he meant when
he said "It should be avoided. Clang has its alternatives."

I commented out my line:
AddPath("/usr/lib/gcc/i386-redhat-linux6E/4.4.4/include", System, true, false,
false);

and not all is well. This left no paths using the AddPath command and only
paths defined with AddGnuCPlusPlusIncludePaths. Only one error now which is the
hello.c bug#9990 I filed for x86 (duplicate for x86_64 is found here bug#8447).
If you don't mind me asking, as I would like to help develop clang now that
I've got me degree and free time ;) , how did you know that it was referencing
the wrong headers? Just good plain ol' experience?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 08:37:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 08:37:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10017] -ffast-math -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns ICEs on channel.f90
In-Reply-To: <bug-10017-206@http.llvm.org/bugs/>
References: <bug-10017-206@http.llvm.org/bugs/>
Message-ID: <20110526133755.D4F152A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10017

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-05-26 08:37:55 CDT ---


*** This bug has been marked as a duplicate of bug 2314 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu May 26 09:01:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 09:01:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10022] New: Ubuntu 11.04 Natty x86: clang++ fails
 to build shared library
Message-ID: <bug-10022-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10022

           Summary: Ubuntu 11.04 Natty x86: clang++ fails to build shared
                    library
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ofv at wanadoo.es
                CC: llvmbugs at cs.uiuc.edu


Source code:


#include <math.h>

double foo(double x) {
  return cos(x);
}


Create a shared library:


clang++ -v -fPIC -O2 -shared foo.cpp

 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_i386
-shared -o a.out /usr/lib/../lib/crti.o
/usr/lib/gcc/i686-linux-gnu/4.5.2/crtbeginS.o
-L/usr/lib/gcc/i686-linux-gnu/4.5.2
-L/usr/lib/gcc/i686-linux-gnu/4.5.2/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i686-linux-gnu/4.5.2/../../..
-L/usr/lib/i686-linux-gnu /tmp/cc-fztJm0.o -lstdc++ -lm -lgcc_s -lc -lgcc_s
/usr/lib/gcc/i686-linux-gnu/4.5.2/crtendS.o /usr/lib/../lib/crtn.o
/usr/bin/ld: /tmp/cc-fztJm0.o: relocation R_386_GOTOFF against undefined symbol
`cos@@GLIBC_2.0' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
clang-3: error: linker command failed with exit code 1 (use -v to see
invocation)


If either -fPIC or -O2 are removed the command succeeds.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 11:10:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 11:10:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10024] New: Assertion hit when specializing a
 member function of a template
Message-ID: <bug-10024-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10024

           Summary: Assertion hit when specializing a member function of a
                    template
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: akyrtzi at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


template <typename T> 
struct Test{ 
template <typename U> 
void get(U i) {}
}; 

template <typename T>
template <> 
void Test<T>::get<double>(double i) {} 

With r132104 I get:

Assertion failed: (isa<LabelDecl>(D) && "declaration not instantiated in this
scope"), function findInstantiationOf, file
/Users/argiris/proj/llvm/src/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp,
line 2263.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 12:03:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 12:03:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10025] New: Missing line in OCaml Kaleidoscope
 tutorial Chapter 3
Message-ID: <bug-10025-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10025

           Summary: Missing line in OCaml Kaleidoscope tutorial Chapter 3
           Product: Website
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: damien.schoof at gmail.com
                CC: llvmbugs at cs.uiuc.edu
        Depends on: 10016


+++ This bug was initially created as a clone of Bug #10016 +++

I've just been working through the Kaleidoscope tutorial online at
http://llvm.org/docs/tutorial/OCamlLangImpl3.html#basics and I've found a
missing line in the section about setting up.  The line has been merged into
the line below it, which is valid, but creates an error a few lines further
down.
The line of code (second code snippet of the section:

        let the_module = create_module (global_context ()) "my cool jit"

but should be:

        let context = global_context ()
        let the_module = create_module context "my cool jit"

found in lines 9 and 10 of codegen.ml.

All that is needed to fix this bug is to replace the line of code with the 2
above, as found in the example code.
This bug applies only to the OCaml version of the tutorial, the C++ version is
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  Thu May 26 14:36:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 14:36:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9683] Assert generated when clang GEP's into nested
 unnamed structs
In-Reply-To: <bug-9683-206@http.llvm.org/bugs/>
References: <bug-9683-206@http.llvm.org/bugs/>
Message-ID: <20110526193605.4EA352A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9683

Max Burke <mburke at ea.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |

--- Comment #2 from Max Burke <mburke at ea.com> 2011-05-26 14:36:04 CDT ---
Hi Douglas,

I've re-verified this with top-of-tree. I added a small main function that
creates an instance of the QueueEntry structure:

int main(void)
{
    QueueEntry QE;
    QE.mValue = 0;
}

And it aborts with a similar, if not the same, callstack:


mburke at D1018130-linux:~/src/tmp$
/home/mburke/src/build/Release+Asserts/bin/clang -D EA_DEBUG -D _DEBUG -D
EA_PLATFORM_LINUX=1  -Wall  -Wno-deprecated-declarations  -fno-rtti 
-fno-exceptions  -Werror  -O0  -fno-strict-aliasing  -g3  -c  -fno-common 
-fshort-wchar  -fmessage-length=0  -m64  -march=athlon64 test2.cpp
clang: /home/mburke/src/llvm/include/llvm/Instructions.h:278: const llvm::Type*
llvm::checkType(const llvm::Type*): Assertion `Ty && "Invalid GetElementPtrInst
indices for type!"' failed.
0  clang           0x0000000001a4285f
1  clang           0x0000000001a4339a
2  libpthread.so.0 0x00007f1589b12c60
3  libc.so.6       0x00007f1588dfdd05 gsignal + 53
4  libc.so.6       0x00007f1588e01ab6 abort + 390
5  libc.so.6       0x00007f1588df67c5 __assert_fail + 245
6  clang           0x000000000081e118
7  clang           0x000000000081e1ff
8  clang           0x000000000082640a
clang::CodeGen::CodeGenFunction::EmitLValueForField(llvm::Value*,
clang::FieldDecl const*, unsigned int) + 346
9  clang           0x00000000008268bb
clang::CodeGen::CodeGenFunction::EmitLValueForFieldInitialization(llvm::Value*,
clang::FieldDecl const*, unsigned int) + 91
10 clang           0x00000000007eb682
clang::CodeGen::CodeGenFunction::EmitCtorPrologue(clang::CXXConstructorDecl
const*, clang::CXXCtorType, clang::CodeGen::FunctionArgList&) + 610
11 clang           0x00000000007ec445
clang::CodeGen::CodeGenFunction::EmitConstructorBody(clang::CodeGen::FunctionArgList&)
+ 133
12 clang           0x00000000008da9ed
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 973
13 clang           0x00000000007d52bf
clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType) + 175
14 clang           0x00000000007b0fb1
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 273
15 clang           0x00000000007b11c3
clang::CodeGen::CodeGenModule::EmitDeferred() + 163
16 clang           0x00000000007b1259 clang::CodeGen::CodeGenModule::Release()
+ 9
17 clang           0x00000000007a45d2
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 98
18 clang           0x00000000008f59bd clang::ParseAST(clang::Sema&, bool) + 333
19 clang           0x00000000007a32c4 clang::CodeGenAction::ExecuteAction() +
68
20 clang           0x00000000006a0423
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
21 clang           0x00000000006799ea
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1130
22 clang           0x000000000066e635 cc1_main(char const**, char const**, char
const*, void*) + 789
23 clang           0x0000000000678993 main + 7283
24 libc.so.6       0x00007f1588de8eff __libc_start_main + 255
25 clang           0x000000000066e139
Stack dump:
0.    Program arguments: /home/mburke/src/build/Release+Asserts/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-main-file-name test2.cpp -mrelocation-model static -mdisable-fp-elim
-relaxed-aliasing -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu athlon64 -target-linker-version 2.21.0.20110327
-momit-leaf-frame-pointer -g -coverage-file test2.o -resource-dir
/home/mburke/src/build/Release+Asserts/bin/../lib/clang/3.0 -D EA_DEBUG -D
_DEBUG -D EA_PLATFORM_LINUX=1 -O0 -Wall -Wno-deprecated-declarations -Werror
-fdeprecated-macro -ferror-limit 19 -fmessage-length 0 -fno-rtti -fgnu-runtime
-fshort-wchar -fno-common -fdiagnostics-show-option -fcolor-diagnostics -o
test2.o -x c++ test2.cpp 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    test2.cpp:34:5: Generating code for declaration 'QueueEntry::QueueEntry'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)


mburke at D1018130-linux:~/src/tmp$
/home/mburke/src/build/Release+Asserts/bin/clang -v
clang version 3.0 (trunk 132125)
Target: x86_64-unknown-linux-gnu
Thread model: posix

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu May 26 15:39:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 15:39:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10026] New: crash
Message-ID: <bug-10026-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10026

           Summary: crash
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jbulow-llvm at jongel.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


In SemaTemplateInstantiateDecl.cpp (rev 132089) in function
Sema::InstantiateFunctionDefinition the use of PatternDecl is not always
checked for NULL before use. 

I have some proprietary code which triggers PattermDecl = NULL.  The crash
happens on line 2344:

if (!Pattern && !PatternDecl->isDefaulted()) {

I'm sorry about the lack of details in this report.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu May 26 15:46:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 15:46:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10027] New: Assertion failure when calling
 ElaboratedTypeLoc::getTypePtr()
Message-ID: <bug-10027-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10027

           Summary: Assertion failure when calling
                    ElaboratedTypeLoc::getTypePtr()
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthewbg at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Consider the following source file:
namespace S { typedef int T; }
const S::T x = 5;

A RecursiveASTVisitor with the following method will assert while visiting the
declaration of 'x':
  bool VisitVarDecl(VarDecl* decl) {
    const TypeLoc type_loc = decl->getTypeSourceInfo()->getTypeLoc();
    if (const ElaboratedTypeLoc* etype_loc =
        dyn_cast<ElaboratedTypeLoc>(&type_loc)) {
      etype_loc->getTypePtr();
    }
    return true;
  }

Here's the relevant part of the stack trace:
#6  0x0000000001626027 in __assert_fail (
    assertion=0x16791a8 "isa<X>(Val) && \"cast<Ty>() argument of incompatible
type!\"",
    file=0x1679170 "include/llvm/Support/Casting.h", line=202,
    function=0x167b960 "typename llvm::cast_retty<To, From>::ret_type
llvm::cast(const Y&) [with X = clang::ElaboratedType, Y = const clang::Type*]")
#7  0x0000000000b1ddb5 in llvm::cast<clang::ElaboratedType, clang::Type const*>
    (Val=@0x7fffffffc678)
    at include/llvm/Support/Casting.h:202
#8  0x0000000000b1c106 in clang::ConcreteTypeLoc<clang::UnqualTypeLoc,
clang::ElaboratedTypeLoc, clang::ElaboratedType,
clang::ElaboratedLocInfo>::getTypePtr (
    this=0x7fffffffc6b0)
    at tools/clang/include/clang/AST/TypeLoc.h:311
#9  0x0000000000af84f5 in BugReproVisitor::VisitVarDecl (this=0x7ffff6bbfe20,
    decl=0x7ffff7f5e450) at repro.cc:22

Here's ElaboratedTypeLoc's getTypePtr(); TypeClass is ElaboratedType and Base
is UnqualTypeLoc:
  const TypeClass *getTypePtr() const {
    return cast<TypeClass>(Base::getTypePtr());
  }

The problem is that UnqualTypeLoc::getTypePtr() is returning a bogus address,
in this case 0x7ffff6c0cfc1 -- note the set low bit, that is, the type that was
stored in the TypeSourceInfo is actually a QualType with a const qualifier.
Oops. Tracing the source of this bit, apparently we build the VarDecl's
TypeSourceInfo from a QualType to which we explicitly add qualifiers (in
ConvertDeclSpecToType()).

There are a couple of hacks that could fix the immediate problem, such as
changing ElaboratedTypeLoc to inherit from QualifiedTypeLoc instead of
UnqualTypeLoc. However, QualifiedTypeLoc does not appear to have gotten much
traction in the codebase, and the TypeLoc type hierarchy has some strange
behavior (see e.g. UnqualTypeLoc::classof(const TypeLoc*)). Maybe it's time to
rip out UnqualTypeLoc and QualifiedTypeLoc, and just deal in QualTypes
everywhere.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 16:09:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 16:09:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10028] New: likely wrong code bug
Message-ID: <bug-10028-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10028

           Summary: likely 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, chenyang at cs.utah.edu


Sorry for the long test case but I already spent a while reducing this.  I
believe the test case is well-defined.

regehr at home:~$ clang -O2 small.c
regehr at home:~$ ./a.out
1
regehr at home:~$ clang -O3 small.c
regehr at home:~$ ./a.out
0
regehr at home:~$ clang -v
clang version 3.0 (trunk 132139)
Target: i386-pc-linux-gnu
Thread model: posix
regehr at home:~$ cat small.c
int printf (const char *, ...);

short safe_15 (short si1, short si2)
{
  return si2 == 0 ? 0 : si1 % si2;
}

short safe_56 (short ui1, short ui2)
{
  return ui2 == 0 ? 1 : ui1 / ui2;
}

int g_31;
long f0;
long f1;

int g_65[2][8][2] = {
  {{}, {}, {}, {0, 1}},
};

int g_72;

void func_57 (void)
{
  int *l_64 = &g_65[1][2][1];
  g_72 = safe_15 (safe_56 (1, f0), *l_64);
  *l_64 &= 1;
}

unsigned g_208; 

int main (void)
{
  for (; f0 < 1; f0 = 1)
    {
      func_57 ();
      for (g_208 = 0; g_208 <= 1; g_208++)
    for (f1 = 0; f1 <= 1; f1++)
      {
        g_65[g_208][g_31 + 2][g_208] = g_65[0][f1 + 2][g_208];
        func_57 ();
      }
    }
  printf ("%d\n", g_65[1][2][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  Thu May 26 17:38:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 17:38:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10029] New: VerifyCoalescing failure on
 patterns_dfa.c of 445.gobmk
Message-ID: <bug-10029-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10029

           Summary: VerifyCoalescing failure on patterns_dfa.c of
                    445.gobmk
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


Running VerifyCoalescing on a TEST=simple build of 445.gobmk gives this
pre-coalescing error on 445.gobmk:

*** Bad machine code: Illegal virtual register for instruction ***
- function:    dfa_add_string
- basic block: create_dfa.exit 0x7fae313042a0 (BB#39) [7072L;7760L)
- instruction: 7168L    %vreg191<def> = LEA64r %vreg42<kill>, 4, %vreg42, 0,
%noreg; GR64:%vreg191,%vreg42,%vreg42
- operand 3:   %vreg42
Expected a GR64_NOSP register, but got a GR64 register

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 17:58:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 17:58:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10030] New: Dead branch warning elimination doesn't
 trigger for global initialisation
Message-ID: <bug-10030-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10030

           Summary: Dead branch warning elimination doesn't trigger for
                    global initialisation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


Consider the following input:

int foo = 1 > 2 ? 1 << -1 : 0;

This results in a warning about the negative shift, even if that branch of the
ternary operator is known to be unused. This does work inside a function e.g.
as statement.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu May 26 18:29:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 18:29:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10026] crash
In-Reply-To: <bug-10026-206@http.llvm.org/bugs/>
References: <bug-10026-206@http.llvm.org/bugs/>
Message-ID: <20110526232943.D1AF42A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10026

Sean Hunt <scshunt at csclub.uwaterloo.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Sean Hunt <scshunt at csclub.uwaterloo.ca> 2011-05-26 18:29:43 CDT ---
This has been fixed in r132089.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 26 19:46:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 26 May 2011 19:46:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10031] New: crash when building with -O3
Message-ID: <bug-10031-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10031

           Summary: crash when building with -O3
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6656)
 --> (http://llvm.org/bugs/attachment.cgi?id=6656)
repro

With the current trunk version ( 132167 ):

thakis$ clang++ repro.ii   -O3
Assertion failed: (HasInsideLoopSuccs && "Loop block has no in-loop
successors!"), function verifyLoop, file
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/include/llvm/Analysis/LoopInfo.h,
line 458.
0  clang             0x0000000101716512 PrintStackTrace(void*) + 34
1  clang             0x0000000101717363 SignalHandler(int) + 707
2  libSystem.B.dylib 0x00007fff8064767a _sigtramp + 26
3  clang             0x0000000100000000 __dso_handle + 0
4  clang             0x000000010001a5c2 __assert_rtn + 66
5  clang             0x00000001014c8b0a llvm::LoopBase<llvm::BasicBlock,
llvm::Loop>::verifyLoop() const + 2858
6  clang             0x00000001014cbbbb
llvm::LPPassManager::runOnFunction(llvm::Function&) + 1627
7  clang             0x00000001016474c0
llvm::FPPassManager::runOnFunction(llvm::Function&) + 752
8  clang             0x000000010147f051 (anonymous
namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, llvm::CallGraphSCC&,
llvm::CallGraph&, bool&, bool&) + 273
9  clang             0x000000010147fad1 (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&) + 1553
10 clang             0x00000001016491cf
llvm::MPPassManager::runOnModule(llvm::Module&) + 607
11 clang             0x00000001016494d1
llvm::PassManagerImpl::run(llvm::Module&) + 177
12 clang             0x00000001016495ed llvm::PassManager::run(llvm::Module&) +
13
13 clang             0x0000000100199262 (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
llvm::raw_ostream*) + 1762
14 clang             0x0000000100199ad4
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 196
15 clang             0x00000001002d643e
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 286
16 clang             0x0000000100308874 clang::ParseAST(clang::Sema&, bool) +
436
17 clang             0x00000001002d496c clang::CodeGenAction::ExecuteAction() +
60
18 clang             0x0000000100058f11
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 433
19 clang             0x0000000100024d25
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1493
20 clang             0x000000010001b8e1 cc1_main(char const**, char const**,
char const*, void*) + 577
21 clang             0x0000000100023b7e main + 4526
22 clang             0x000000010001ad14 start + 52
23 clang             0x0000000000000025 start + 4294857541


delta's running?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri May 27 00:05:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 00:05:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10029] VerifyCoalescing failure on patterns_dfa.c
	of 445.gobmk
In-Reply-To: <bug-10029-206@http.llvm.org/bugs/>
References: <bug-10029-206@http.llvm.org/bugs/>
Message-ID: <20110527050513.9F32A2A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10029

Cameron Zwarich <zwarich at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Cameron Zwarich <zwarich at apple.com> 2011-05-27 00:05:13 CDT ---
Fixed in r132181.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 00:18:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 00:18:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10032] New: VerifyCoalescing failure on espresso
Message-ID: <bug-10032-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10032

           Summary: VerifyCoalescing failure on espresso
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


I get the following -verify-coalescing failure on espresso using TEST=nightly:

*** Bad machine code: Illegal virtual register for instruction ***
- function:    sf_sort
- basic block: if.then.i 0x7fc0919e9f98 (BB#5) [1168L;1568L)
- instruction: 1344L    %vreg84<def> = ADD32rm %vreg84, %vreg50, 4,
%vreg56<kill>, 0, %noreg, %EFLAGS<imp-def,dead>;
mem:LD4[%arrayidx16.i](tbaa=!"int") GR32:%vreg84 GR64:%vreg50
GR64_NOREX:%vreg56
- operand 4:   %vreg56<kill>
Expected a GR64_NOSP register, but got a GR64_NOREX register
LLVM ERROR: Found 1 machine code 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  Fri May 27 00:19:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 00:19:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10026] crash
In-Reply-To: <bug-10026-206@http.llvm.org/bugs/>
References: <bug-10026-206@http.llvm.org/bugs/>
Message-ID: <20110527051906.0F6712A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10026

Jonas B?low <jbulow-llvm at jongel.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #2 from Jonas B?low <jbulow-llvm at jongel.net> 2011-05-27 00:19:05 CDT ---
In rev 132175 the crash has been moved to line 2410:


  for (unsigned I = 0, N = PatternDecl->getNumParams(); I != N; ++I) {

(PatternDecl is 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  Fri May 27 03:12:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 03:12:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10015] -O3 -fplugin-arg-dragonegg-enable-gcc-optzns
 ICEs compiler for rnflow.f90
In-Reply-To: <bug-10015-206@http.llvm.org/bugs/>
References: <bug-10015-206@http.llvm.org/bugs/>
Message-ID: <20110527081254.CFD1C2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10015

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-05-27 03:12:54 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110523/121534.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 May 27 04:38:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 04:38:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9710] -O3 -fplugin-arg-dragonegg-enable-gcc-optzns
 fails to compile capacita.f90
In-Reply-To: <bug-9710-206@http.llvm.org/bugs/>
References: <bug-9710-206@http.llvm.org/bugs/>
Message-ID: <20110527093843.916812A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9710

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2011-05-27 04:38:42 CDT ---
Tracking sqrtps_nr in PR9716.

*** This bug has been marked as a duplicate of bug 9716 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 07:48:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 07:48:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10033] New: -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns miscompiles rnflow.f90
Message-ID: <bug-10033-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10033

           Summary: -O3 -fplugin-arg-dragonegg-enable-gcc-optzns
                    miscompiles rnflow.f90
           Product: dragonegg
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


While at r132184, the rnflow test case can be compiled with -O3
-fplugin-arg-dragonegg-enable-gcc-optzns, it appears to be miscompiled and runs
very slowly compared to when compiled with -O3
-fplugin-arg-dragonegg-enable-gcc-optzns -fno-tree-vectorize...

[MacPro:pb05/lin/source] howarth% /sw/lib/gcc4.5/bin/gfortran
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -O3
-fplugin-arg-dragonegg-enable-gcc-optzns rnflow.f90 -fno-tree-vectorize -o
rnflow
[MacPro:pb05/lin/source] howarth% ./rnflow                                     
                                                                               
0: 0: 0.000 -> Read sequence
  0: 0: 1.146 -> extract extrema
  0: 0: 1.151 -> Generate raw transitions counts
  0: 0: 1.157 -> Compute Markov matrix
  0: 0: 1.158 -> Calculate theoretical rainflow
  0: 0:15.769 -> Simulate random markov sequences
  0: 0:15.959 -> Completed simulation #    1
  0: 0:16.149 -> Completed simulation #    2

[MacPro:pb05/lin/source] howarth% /sw/lib/gcc4.5/bin/gfortran
-fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -O3
-fplugin-arg-dragonegg-enable-gcc-optzns rnflow.f90 -o rnflow
[MacPro:pb05/lin/source] howarth% ./rnflow                                     
                                                                               
0: 0: 0.001 -> Read sequence
  0: 0: 1.151 -> extract extrema
  0: 0: 1.157 -> Generate raw transitions counts
  0: 0: 1.163 -> Compute Markov matrix
  0: 0: 1.163 -> Calculate theoretical rainflow
  0: 2:47.038 -> Simulate random markov sequences

where the time required for "Calculate theoretical rainflow" has increased 11
fold and the completed simulations never appear. Since -fno-tree-vectorize
eliminates the problem it must lie in the vectorization optimizations.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri May 27 09:22:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 09:22:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10034] New: Spurious error
Message-ID: <bug-10034-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10034

           Summary: Spurious error
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: csaba_22 at yahoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6660)
 --> (http://llvm.org/bugs/attachment.cgi?id=6660)
The problematic file

clang++ version 3.0 (trunk 132119)
Target: x86_64-unknown-linux-gnu
Thread model: posix

emits an error for the following code:

void puts(const char*);

struct X {};

void exx(X) {}

int main(int argc, char **argv)
{
 if (argc > 3)
   goto end;

 X x;
 exx(x);

 end:

   for (int i = 0; i < argc; ++i)
   {
     puts(argv[i]);
   }

   return 0;
}

c.cc:10:5: error: goto into protected scope
   goto end;
   ^
c.cc:12:5: note: jump bypasses variable initialization
 X x;
   ^

No errors from g++ version 4.5.0 20100604 [gcc-4_5-branch revision 160292]

Comeau online:

Comeau C/C++ 4.3.10.1 (Oct  6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:strict errors C++ C++0x_extensions

In strict mode, with -tused, Compile succeeded

clang has been outvoted 2:1 :)

Csaba
P.S. compilation succeeds if the for loop is commented out.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri May 27 10:04:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 10:04:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10035] New: noexcept can't reference function
	arguments
Message-ID: <bug-10035-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10035

           Summary: noexcept can't reference function arguments
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Apple clang version 3.0 (trunk 131788) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

Here is a minimal test case:


template <class T>
struct some_trait
{
    static const bool value = true;
};

template <class T>
void
swap(T& x, T& y) noexcept(some_trait<T>::value);

template <class ForwardIterator1, class ForwardIterator2>
inline
void
iter_swap(ForwardIterator1 a, ForwardIterator2 b)
                                                noexcept(noexcept(swap(*a,
*b)))
{
    swap(*a, *b);
}

int main()
{
    int i = 0, j = 0;
    iter_swap(&i, &j);
}


test.cpp:16:73: error: reference to local variable 'a' declared in enclosed
function 'iter_swap'
                                                noexcept(noexcept(swap(*a,
*b)))
                                                                        ^
test.cpp:15:1: note: in instantiation of function template specialization
'iter_swap<int *, int *>' requested here
iter_swap(ForwardIterator1 a, ForwardIterator2 b)
^
test.cpp:15:28: note: 'a' declared here
iter_swap(ForwardIterator1 a, ForwardIterator2 b)
                           ^
1 error generated.

The expectation is for this to compile because 'a' and 'b' are in scope.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 10:04:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 10:04:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10036] New: noexcept can't reference member data
Message-ID: <bug-10036-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10036

           Summary: noexcept can't reference member data
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Apple clang version 3.0 (trunk 131788) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

Here is a minimal test case:


template <class I>
void
iter_swap(I x, I y) noexcept;

template <class T>
class A
{
    T t_;
public:
    void swap(A& a) noexcept(noexcept(iter_swap(&t_, &a.t_)));
};

int main()
{
    A<int> i, j;
    i.swap(j);
}


test.cpp:10:56: error: member access into incomplete type 'A<int>'
    void swap(A& a) noexcept(noexcept(iter_swap(&t_, &a.t_)));
                                                       ^
test.cpp:15:12: note: in instantiation of template class 'A<int>' requested
here
    A<int> i, j;
           ^
test.cpp:6:7: note: definition of 'A<int>' is not complete until the closing
'}'
class A
      ^
1 error generated.

The expectation is for this to compile.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri May 27 10:26:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 10:26:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10033] -O3 -fplugin-arg-dragonegg-enable-gcc-optzns
 miscompiles rnflow.f90
In-Reply-To: <bug-10033-206@http.llvm.org/bugs/>
References: <bug-10033-206@http.llvm.org/bugs/>
Message-ID: <20110527152649.EFD822A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10033

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-05-27 10:26:49 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110523/121543.html
The resulting code is pretty rotten.  In fact when compiled without
-fplugin-arg-dragonegg-enable-gcc-optzns I see rnflow running faster than
when compiled with gcc-4.5; with -fplugin-arg-dragonegg-enable-gcc-optzns it
runs slower than gcc-4.5.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 10:33:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 10:33:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10037] New: Poor code generated for whole-vector
	shifts
Message-ID: <bug-10037-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10037

           Summary: Poor code generated for whole-vector shifts
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Consider this:

define <4 x i32> @lshr(<4 x i32> %x) {
  %a = bitcast <4 x i32> %x to i128
  %b = lshr i128 %a, 32
  %c = bitcast i128 %b to <4 x i32>
  ret <4 x i32> %c
}

it codegens to:

        movd    %xmm0, %rcx
        pextrq  $1, %xmm0, %rax
        shrdq   $32, %rax, %rcx
        movd    %rcx, %xmm0
        shrq    $32, %rax
        movd    %rax, %xmm1
        punpcklqdq      %xmm1, %xmm0    # xmm0 = xmm0[0],xmm1[0]

however it could codegen to a simple
        psrldq
since the shift is by a multiple of 8.

The best way to solve this might be to turn this construct into a shufflevector
at the IR level.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri May 27 11:05:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 11:05:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10034] Invalid "goto into protected scope" error
In-Reply-To: <bug-10034-206@http.llvm.org/bugs/>
References: <bug-10034-206@http.llvm.org/bugs/>
Message-ID: <20110527160540.705392A6C12F@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10034

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-05-27 11:05:39 CDT ---
Fixed in Clang r132191.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 12:00:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 12:00:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10038] New: clang++ generates HIDDEN symbols where
	g++ doesn't
Message-ID: <bug-10038-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10038

           Summary: clang++ generates HIDDEN symbols where g++ doesn't
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: fischman at chromium.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6661)
 --> (http://llvm.org/bugs/attachment.cgi?id=6661)
repro case for clang++/g++ differenc

For the attached source file, I get this:

$ clang++ -c -fvisibility-inlines-hidden -fvisibility=hidden visibility.cc &&
readelf -Ws visibility.o |c++filt |fgrep 'std::basic_string<unsigned short,
base::string16_char_traits, std::allocator<unsigned short> >::insert(unsigned
long, unsigned short const*)' && g++ -c -fvisibility-inlines-hidden
-fvisibility=hidden visibility.cc && readelf -Ws visibility.o |c++filt |fgrep
'std::basic_string<unsigned short, base::string16_char_traits,
std::allocator<unsigned short> >::insert(unsigned long, unsigned short const*)'
  630: 0000000000000000    79 FUNC    WEAK   HIDDEN  458
std::basic_string<unsigned short, base::string16_char_traits,
std::allocator<unsigned short> >::insert(unsigned long, unsigned short const*)
  582: 0000000000000000    66 FUNC    WEAK   DEFAULT  399
std::basic_string<unsigned short, base::string16_char_traits,
std::allocator<unsigned short> >::insert(unsigned long, unsigned short const*)

Note that whereas clang++ generates a HIDDEN symbol, g++ generates a DEFAULT
(public) symbol.  What's up with that?

(note that both -fvisibility-inlines-hidden -fvisibility=hidden are specified;
if only one is specified then different symbols in std::basic_string are
DEFAULT or HIDDEN, depending on whether they got inlined or not).

This came up in the context of making chromium's component=shared_library build
work with clang (it works fine w/ gcc).  For details on this build style see
https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/846e33b3952f726/80ca2a622a05ed85#

Version info: this is all on a lucid ubuntu box and:
clang version 3.0 (trunk 131935)
Target: x86_64-unknown-linux-gnu
Thread model: posix
and:
g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri May 27 14:23:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 14:23:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10039] New: False positive warning indicating dead
 code on nested loop variable reuse
Message-ID: <bug-10039-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10039

           Summary: False positive warning indicating dead code on nested
                    loop variable reuse
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: paul at eipper.com.br
                CC: llvmbugs at cs.uiuc.edu


Upon reusing a variable declared outside the loop scope that has an initial
value of zero on a nested loop, the analyzer reports a warning that the
variable is always zero.


Attached is a reduced test case, this is the output I see from clang for that
file:

`
clang --analyze test.m 
test.m:14:28: warning: The left operand to '+' is always 0
        for (j = i; j < (i + 3); j++) {
                         ~ ^
1 warning generated.
`

This issue was initially observed in live code on the ASI HTTP Request library:
https://github.com/pokeb/asi-http-request/blob/4d909a63a0ce6a1c3cde8526159ed7f91b6568ee/Classes/ASIHTTPRequest.m#L4528

Reported (and a fix released) here:
https://github.com/pokeb/asi-http-request/issues/165

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 15:13:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 15:13:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10026] Sema::InstantiateFunctionDefinition doesn't
 handle null pattern decls
In-Reply-To: <bug-10026-206@http.llvm.org/bugs/>
References: <bug-10026-206@http.llvm.org/bugs/>
Message-ID: <20110527201304.AB9522A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10026

Sean Hunt <scshunt at csclub.uwaterloo.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Sean Hunt <scshunt at csclub.uwaterloo.ca> 2011-05-27 15:13:04 CDT ---
It was actually a bug in IWYU; it was calling for the instantiation of a
non-template function. There's an IWYU fix which will go out with the next code
push; watch that bug. I've added asserts to clang to make it more clear in the
future that this is intended behavior.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri May 27 16:08:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 16:08:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10040] New: Assertion `0 && "Invalid for compares"'
	failed.
Message-ID: <bug-10040-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10040

           Summary: Assertion `0 && "Invalid for compares"' 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 gamow ~]$ clang -v
clang version 3.0 (trunk 132199)
Target: x86_64-unknown-linux-gnu
Thread model: posix
[regehr at gamow ~]$ clang -O2 small.c -c
clang: ConstantFolding.cpp:832: llvm::Constant*
llvm::ConstantFoldInstOperands(unsigned int, const llvm::Type*, llvm::Constant*
const*, unsigned int, const llvm::TargetData*): Assertion `0 && "Invalid for
compares"' failed.
0  clang           0x000000000190320f
1  clang           0x0000000001905482
2  libpthread.so.0 0x00007ffff7bcf8f0
3  libc.so.6       0x00007ffff6ebea75 gsignal + 53
4  libc.so.6       0x00007ffff6ec25c0 abort + 384
5  libc.so.6       0x00007ffff6eb7941 __assert_fail + 241
6  clang           0x00000000016fc1ff llvm::ConstantFoldInstOperands(unsigned
int, llvm::Type const*, llvm::Constant* const*, unsigned int, llvm::TargetData
const*) + 591
7  clang           0x0000000001684299
8  clang           0x0000000001685621
9  clang           0x0000000001685bfa
10 clang           0x0000000001641f81
11 clang           0x00000000016432ce
12 clang           0x000000000184d1bb
llvm::FPPassManager::runOnFunction(llvm::Function&) + 587
13 clang           0x00000000016e661d
14 clang           0x000000000184e897
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
15 clang           0x000000000184ea2b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
16 clang           0x00000000007cbda8
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 1720
17 clang           0x00000000007c93db
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
18 clang           0x00000000008fb37d clang::ParseAST(clang::Sema&, bool) + 413
19 clang           0x00000000007c86a4 clang::CodeGenAction::ExecuteAction() +
68
20 clang           0x00000000006b0e33
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
21 clang           0x000000000068b2c4
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1268
22 clang           0x0000000000681948 cc1_main(char const**, char const**, char
const*, void*) + 760
23 clang           0x000000000068a180 main + 7040
24 libc.so.6       0x00007ffff6ea9c4d __libc_start_main + 253
25 clang           0x000000000067fd79
Stack dump:
0.    Program arguments:
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r132199-install/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
small.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -coverage-file small.o -resource-dir
/uusoc/exports/scratch/regehr/z/compiler-install/llvm-gcc-r132199-install/bin/../lib/clang/3.0
-O2 -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 'Combine redundant instructions' on function '@func_13'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
[regehr at gamow ~]$ cat small.c
int g_3;
int *g_59;
static char g_245;
int *g_563;

static void func_21 (short p_22)
{
  int *l_640 = &g_3;
  if (*g_59)
    for (;; g_245 = 1);
  for (;;)
    {
      *l_640 = p_22 < 1 && (p_22 || g_245);
      *g_563 = 1;
    }
}

int *func_13 (int **p_14, int *p_15)
{
  short l_20[1];
  int i;
  for (i = 0; i < 1; i++)
    l_20[i] = 0;
  func_21 (l_20[0]);
  return 0;
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri May 27 20:29:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 20:29:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10041] New: add support for -fgnu89-inline
Message-ID: <bug-10041-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10041

           Summary: add support for -fgnu89-inline
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


Yep, I've found code that says "-std=c99 -fgnu89-inline". It does what you'd
expect, it changes the interpretation of the inline keyword to be the same as
the same as the old GNU extension. Upstream documentation:
http://gcc.gnu.org/onlinedocs/gcc/Inline.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 May 27 20:44:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 20:44:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10042] New:
 -fplugin-arg-dragonegg-enable-gcc-optzns -O3 -fdefault-integer-8 ICE
Message-ID: <bug-10042-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10042

           Summary: -fplugin-arg-dragonegg-enable-gcc-optzns -O3
                    -fdefault-integer-8 ICE
           Product: dragonegg
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6663)
 --> (http://llvm.org/bugs/attachment.cgi?id=6663)
testcase reduced from source/hbuild.f from xplor-nih 2.27

While attempting to build xplor-nih with
-fplugin-arg-dragonegg-enable-gcc-optzns  -O3, I discovered a new type of ICE
which can be demonstrated with the attached reduced test case (provide as a
tar.gz because of the required fcm files)...

[MacPro:~/debug5] howarth% de-gfortran45 -c hbuild_reduced.f -g
-fplugin-arg-dragonegg-enable-gcc-optzns -fdefault-integer-8
-ffixed-line-length-120 -fno-second-underscore -O3  <array_type 0x14a5482a0
    type <integer_type 0x149a3f1f8 character(kind=1) public unsigned
string-flag QI
        size <integer_cst 0x149a2f758 constant 8>
        unit size <integer_cst 0x149a2f780 constant 1>
        align 8 symtab 0 alias set 5 canonical type 0x149a3f1f8 precision 8 min
<integer_cst 0x149a2f7a8 0> max <integer_cst 0x149a2f7d0 255>
        pointer_to_this <pointer_type 0x149a52d20>>
    string-flag SI
    size <integer_cst 0x149a2f988 type <integer_type 0x149a3f0a8 bit_size_type>
constant 32>
    unit size <integer_cst 0x149a2f690 type <integer_type 0x149a3f000> constant
4>
    align 8 symtab 0 alias set 5 canonical type 0x14a5482a0
    domain <integer_type 0x14a5481f8
        type <integer_type 0x149a3f498 integer(kind=4) public SI size
<integer_cst 0x149a2f988 32> unit size <integer_cst 0x149a2f690 4>
            align 32 symtab 0 alias set 8 canonical type 0x149a3f498 precision
32 min <integer_cst 0x149a2f910 -2147483648> max <integer_cst 0x149a2f938
2147483647>
            pointer_to_this <pointer_type 0x149a4c3f0>>
        SI size <integer_cst 0x149a2f988 32> unit size <integer_cst 0x149a2f690
4>
        align 32 symtab 0 alias set -1 canonical type 0x14a5481f8 precision 32
min <integer_cst 0x149a2fed8 1> max <integer_cst 0x14a53d7a8 4>>
    pointer_to_this <pointer_type 0x14a608c78>>
*** 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
hbuild_reduced.f: In function ?hbuil2_?:
hbuild_reduced.f:4:0: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This ICE is suppressed with the addition of -fno-tree-vectorize. FYI, this
issue occurs in several other files within xplor-nih.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 27 20:50:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 27 May 2011 20:50:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10039] False positive warning indicating dead code
 on nested loop variable reuse
In-Reply-To: <bug-10039-206@http.llvm.org/bugs/>
References: <bug-10039-206@http.llvm.org/bugs/>
Message-ID: <20110528015053.F3D652A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10039

Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kremenek at apple.com
         Resolution|                            |FIXED

--- Comment #2 from Ted Kremenek <kremenek at apple.com> 2011-05-27 20:50:53 CDT ---
This has been fixed for a while 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 May 28 03:02:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 28 May 2011 03:02:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10043] New: Failure to warn about inaccessible copy
 constructor of member of class in -Wbind-to-temporary-copy
Message-ID: <bug-10043-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10043

           Summary: Failure to warn about inaccessible copy constructor of
                    member of class in -Wbind-to-temporary-copy
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: scshunt at csclub.uwaterloo.ca
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Consider the following code:

% cat y.cc
struct X {
  X();
private:
  X(const X&) {};
};
struct Y {
  X x;
};
struct Z {
  Z();
  X x;
private:
  Z(const Z&);
};

extern void f(const X&);
extern void g(const Y&);
extern void h(const Z&);

void test() {
  f(X());
  g(Y());
  h(Z());
}

% ./bin/clang -fsyntax-only -std=c++98 -Wall y.cc
y.cc:21:5: warning: C++98 requires an accessible copy constructor for class 'X'
when binding a reference to a temporary; was private [-Wbind-to-temporary-copy]
  f(X());
    ^
y.cc:4:3: note: declared private here
  X(const X&) {};
  ^
y.cc:23:5: warning: C++98 requires an accessible copy constructor for class 'Z'
when binding a reference to a temporary; was private [-Wbind-to-temporary-copy]
  h(Z());
    ^
y.cc:13:3: note: declared private here
  Z(const Z&);
  ^
2 warnings generated.

Why doesn't g(Y()) warn? I feel certain that it used to; I think this is a
regression due to the recent work done on copy constructors, especially
implicit ones...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 05:17:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 28 May 2011 05:17:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10040] Assertion `0 && "Invalid for compares"'
	failed.
In-Reply-To: <bug-10040-206@http.llvm.org/bugs/>
References: <bug-10040-206@http.llvm.org/bugs/>
Message-ID: <20110528101712.71E382A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10040

Benjamin Kramer <benny.kra at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2011-05-28 05:17:11 CDT ---
Fixed in r132254.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 08:37:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 28 May 2011 08:37:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10044] New: Scoped enumeration instantiated even if
 not required
Message-ID: <bug-10044-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10044

           Summary: Scoped enumeration instantiated even if not required
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Clang should not instantiate the definition of the scoped enumeration:


template<typename T>
struct A {
  enum class B {
    X = T::value
  };
};

int main() {
  A<int> a;
}

Clang error:

main1.cpp:4:9: error: type 'int' cannot be used prior to '::' because it has no
members
    X = T::value

This code looks well-formed. Only if we look into the enumeration, as
"A<int>::B::X", the definition of the enumeration is required to exist and thus
implicitly instantiated. This is specified at 14.7.1p1 and p2.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 28 14:34:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 28 May 2011 14:34:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10018] -ffast-math -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns ICEs on doduc.f90
In-Reply-To: <bug-10018-206@http.llvm.org/bugs/>
References: <bug-10018-206@http.llvm.org/bugs/>
Message-ID: <20110528193449.2508D2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10018

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #6 from Duncan Sands <baldrick at free.fr> 2011-05-28 14:34:48 CDT ---
Since PR2314 is the only issue left here, marking as a duplicate rather than as
being blocked by PR2314.

*** This bug has been marked as a duplicate of bug 2314 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun May 29 07:40:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 29 May 2011 07:40:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10045] New: [PATCH] fix linking on Linux
Message-ID: <bug-10045-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10045

           Summary: [PATCH] fix linking on Linux
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: bugzillas at petteriraty.eu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6664)
 --> (http://llvm.org/bugs/attachment.cgi?id=6664)
buildit.patch

By default if you follow the instructions you get the problems reported here:

http://thread.gmane.org/gmane.comp.compilers.clang.devel/12942

Using the attached patch and the live ebuild here I was able to use clang++
with libcxx.

http://git.overlays.gentoo.org/gitweb/?p=dev/betelgeuse.git;a=blob;f=sys-libs/libcxx/libcxx-9999.ebuild;h=67b0ff9e1af3b47c59cedebf1213c3cfbe7462a3;hb=0d152a8fdc5e346a07980e61163e114a9f92f9ac

$ clang++ -std=c++0x -stdlib=libc++ test.cpp -o test_clang
$ ./test_clang
Calling foo
?<A?o??w??o?8_????y????????o??w?_??????o??w??o??<A?o??w??o?8_????y?P??0???o??w?_??0???o??w??o?

The garbage seems to be a known bug (#8992).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 29 09:56:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 29 May 2011 09:56:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10046] New: The Mips code generator fails during
 the Greedy Register Allocator pass.
Message-ID: <bug-10046-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10046

           Summary: The Mips code generator fails during the Greedy
                    Register Allocator pass.
           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: rich at pennware.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6665)
 --> (http://llvm.org/bugs/attachment.cgi?id=6665)
LLVM assembly test case.

The attached test cases fails for Mips:

[~/ellcc/libecc/obj/mips/linux/c] main% ~/vendor/llvm-build/bin/llc
MipsGRAassert.ll 
llc: /home/rich/vendor/llvm-build/llvm/lib/CodeGen/SplitKit.cpp:180: bool
llvm::SplitAnalysis::calcLiveBlockInfo(): Assertion `BI.FirstUse >= Start'
failed.
0  llc             0x0000000000f4b6cf
1  llc             0x0000000000f4c20a
2  libpthread.so.0 0x00000037bea0eeb0
3  libc.so.6       0x00000037bde330c5 gsignal + 53
4  libc.so.6       0x00000037bde34a76 abort + 390
5  libc.so.6       0x00000037bde2b905 __assert_fail + 245
6  llc             0x0000000000be0777
7  llc             0x0000000000be0b20 llvm::SplitAnalysis::analyzeUses() + 512
8  llc             0x0000000000b7fcda
9  llc             0x0000000000b697bb llvm::RegAllocBase::allocatePhysRegs() +
267
10 llc             0x0000000000b7ce4b
11 llc             0x0000000000e7ac1f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 655
12 llc             0x0000000000e7acdb
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
13 llc             0x0000000000e7a717
llvm::MPPassManager::runOnModule(llvm::Module&) + 551
14 llc             0x0000000000e7a87b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
15 llc             0x000000000055524a main + 4970
16 libc.so.6       0x00000037bde1ee5d __libc_start_main + 253
17 llc             0x0000000000552f69
Stack dump:
0.      Program arguments: /home/rich/vendor/llvm-build/bin/llc
MipsGRAassert.ll 
1.      Running pass 'Function Pass Manager' on module 'MipsGRAassert.ll'.
2.      Running pass 'Greedy Register Allocator' on function '@mergesort'
Abort (core dumped)
[~/ellcc/libecc/obj/mips/linux/c] main%

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun May 29 12:36:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 29 May 2011 12:36:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10047] New: LLVM doesn't optimize a constructor
 that memsets-to-0 on a zero-initialized global
Message-ID: <bug-10047-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10047

           Summary: LLVM doesn't optimize a constructor that memsets-to-0
                    on a zero-initialized global
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


Following code:

struct A {
  A():a() { }
  int a[100];
};

A a;

$ clang++ -S -O3 -emit-llvm main1.cpp -o -

This output can be further optimized:

; ModuleID = 'main1.cpp'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
target triple = "i386-pc-linux-gnu"

%0 = type { i32, void ()* }
%struct.A = type { [100 x i32] }

@a = global %struct.A zeroinitializer, align 4
@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()*
@_GLOBAL__I_a }]

declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, i1) nounwind

define internal void @_GLOBAL__I_a() nounwind {
  tail call void @llvm.memset.p0i8.i64(i8* bitcast (%struct.A* @a to i8*), i8
0, i64 400, i32 4, i1 false) nounwind
  ret void
}

The memset setting "@a" to zero can be optimized away, because it is already
zero. I was told to make a PR for this by nicholas on IRC.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 29 13:42:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 29 May 2011 13:42:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10047] LLVM doesn't optimize a constructor that
 memsets-to-0 on a zero-initialized global
In-Reply-To: <bug-10047-206@http.llvm.org/bugs/>
References: <bug-10047-206@http.llvm.org/bugs/>
Message-ID: <20110529184219.1F7E42A6C130@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10047

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nlewycky at google.com
          Component|Core LLVM classes           |Interprocedural
                   |                            |Optimizations
         Resolution|                            |FIXED

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2011-05-29 13:42:18 CDT ---
Fixed in r132288.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 29 14:58:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 29 May 2011 14:58:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10045] [PATCH] fix linking on Linux
In-Reply-To: <bug-10045-206@http.llvm.org/bugs/>
References: <bug-10045-206@http.llvm.org/bugs/>
Message-ID: <20110529195848.136DF2A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10045

Petteri R?ty <bugzillas at petteriraty.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Petteri R?ty <bugzillas at petteriraty.eu> 2011-05-29 14:58:47 CDT ---
No objections here as the patch was committed verbatim.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 May 29 15:10:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 29 May 2011 15:10:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10046] The Mips code generator fails during the
 Greedy Register Allocator pass.
In-Reply-To: <bug-10046-206@http.llvm.org/bugs/>
References: <bug-10046-206@http.llvm.org/bugs/>
Message-ID: <20110529201049.A21602A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10046

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-05-29 15:10:49 CDT ---
Fixed in r132298

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 02:46:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 02:46:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10048] New: llc 2.9 doesn't care of packed
 attribute to generate code for x86 target
Message-ID: <bug-10048-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10048

           Summary: llc 2.9 doesn't care of packed attribute to generate
                    code for x86 target
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: babslachem at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hi all,

It seems that there is a regression in LLVM 2.9 vs LLVM 2.8 with respect of
handling packed structure and mis-aligned memory accesses. Here is an example
that illustrate the problem.

Command line used is llc -march=x86 foo.ll -o foo.s

Here is LLVM code sample:

%struct.sType = type < { < 4 x float >, < 4 x float >, < 4 x float > } >
@A = common global < 4 x float > zeroinitializer
@B = common global < 4 x float > zeroinitializer
@C = common global < 4 x float > zeroinitializer
define void @bar(%struct.sType* byval %s) {
L.entry:
    %0 = bitcast %struct.sType* %s to < 4 x float >*
    %1 = load < 4 x float >* %0, align 1
    store < 4 x float > %1, < 4 x float >* @A, align 1
    %2 = bitcast %struct.sType* %s to < 4 x float >*
    %3 = load < 4 x float >* %2, align 1
    store < 4 x float > %3, < 4 x float >* @B, align 1
    %4 = bitcast %struct.sType* %s to < 4 x float >*
    %5 = load < 4 x float >* %4, align 1
    store < 4 x float > %5, < 4 x float >* @C, align 1
    ret void
}
define void @foo(%struct.sType* byval %x) {
L.entry:
    call void  @bar (%struct.sType* byval %x)
    ret void
}

struct.sType is declared as a packed structure so it is considered as one byte
aligned. Using LLVM 2.9, I've got following assembly:

...
bar:                                    # @bar
.Leh_func_begin0:
# BB#0:                                 # %L.entry
    movaps  4(%esp), %xmm0
    movaps  %xmm0, A
    movaps  4(%esp), %xmm0
    movaps  %xmm0, B
    movaps  4(%esp), %xmm0
    movaps  %xmm0, C
    ret
...
foo:                                    # @foo
.Leh_func_begin1:
# BB#0:                                 # %L.entry
    subl    $60, %esp
.Ltmp1:
    movaps  96(%esp), %xmm0
    movaps  %xmm0, 32(%esp)
    movaps  64(%esp), %xmm0
    movaps  80(%esp), %xmm1
    movaps  %xmm1, 16(%esp)
    movaps  %xmm0, (%esp)
    calll   bar
    addl    $60, %esp
    ret
...

As you can see movaps is used in bar to access structure member however
accesses are performed with align 1 attribute. Moreover, in foo a copy is
performed using movaps.
Now if I compile using LLC 2.8, I've got following assembly:

...
bar:                                    # @bar
.Leh_func_begin0:
# BB#0:                                 # %L.entry
    movups  4(%esp), %xmm0
    movaps  %xmm0, A
    movups  4(%esp), %xmm0
    movaps  %xmm0, B
    movups  4(%esp), %xmm0
    movaps  %xmm0, C
    ret
...
foo:                                    # @foo
.Leh_func_begin1:
# BB#0:                                 # %L.entry
    subl    $52, %esp
.Ltmp1:
    movsd   96(%esp), %xmm0
    movsd   %xmm0, 40(%esp)
    movsd   88(%esp), %xmm0
    movsd   %xmm0, 32(%esp)
    movsd   80(%esp), %xmm0
    movsd   %xmm0, 24(%esp)
    movsd   72(%esp), %xmm0
    movsd   %xmm0, 16(%esp)
    movsd   56(%esp), %xmm0
    movsd   64(%esp), %xmm1
    movsd   %xmm1, 8(%esp)
    movsd   %xmm0, (%esp)
    call    bar
    addl    $52, %esp
    ret
...

Which seems to be correct, since structure accesses in bar are performed using
movups instead of moveaps and struct copy in foo is done use movsd.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 06:01:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 06:01:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8782] Linking fails because weird symbol issue
In-Reply-To: <bug-8782-206@http.llvm.org/bugs/>
References: <bug-8782-206@http.llvm.org/bugs/>
Message-ID: <20110530110120.368ED2A6C12E@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8782

jpakkane at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 06:03:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 06:03:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10049] New: SVN trunk will not build
Message-ID: <bug-10049-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10049

           Summary: SVN trunk will not build
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jpakkane at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I'm building SVN trunk on Ubuntu natty 64 bit using CMake. Building fails with
this:

[ 87%] Building CXX object
tools/clang/lib/Frontend/CMakeFiles/clangFrontend.dir/VerifyDiagnosticsClient.cpp.o
[ 88%] Building CXX object
tools/clang/lib/Frontend/CMakeFiles/clangFrontend.dir/Warnings.cpp.o
Linking CXX static library ../../../../lib/libclangFrontend.a
[ 88%] Built target clangFrontend
make[2]: *** No rule to make target `../include/llvm/Support/StandardPasses.h',
needed by
`tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/BackendUtil.cpp.o'.  Stop.
make[1]: *** [tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/all] Error 2

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 08:31:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 08:31:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10050] New: cmake build system doesn't generate
	manpages
Message-ID: <bug-10050-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10050

           Summary: cmake build system doesn't generate manpages
           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: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu


autoconf based system checks for groff and generates man pages from the pod
files, cmake buildsystem should do the same and install the manpages on make
install.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 08:56:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 08:56:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10049] SVN trunk will not build
In-Reply-To: <bug-10049-206@http.llvm.org/bugs/>
References: <bug-10049-206@http.llvm.org/bugs/>
Message-ID: <20110530135657.E82042A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10049

jpakkane at gmail.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  Mon May 30 08:59:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 08:59:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10051] New: Toolchain check broken (since the last
 change, r131256)
Message-ID: <bug-10051-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10051

           Summary: Toolchain check broken (since the last change,
                    r131256)
           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: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


To test if a toolchain is valid, the compiler-rt script uses (since r131256)
the following test:

      if $(CC) -arch $$arch -dumpversion > /dev/null; then \
        result="$$result$$arch "; \
      fi; \

Unfortunately, this test always pass when CC is clang. clang does not check the
architecture when using -dumpversion

$clang -arch foo -dumpversion
4.2.1

And it does not check at all if there is a suitable assembler and linker to
build the compiler-rt library.

And unfortunately again, CC is always clang when compiler-rt is compiled
automatically with clang.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 15:15:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 15:15:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10048] llc 2.9 doesn't care of packed attribute to
 generate code for x86 target
In-Reply-To: <bug-10048-206@http.llvm.org/bugs/>
References: <bug-10048-206@http.llvm.org/bugs/>
Message-ID: <20110530201512.DFF8E2A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10048

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #6 from Chris Lattner <clattner at apple.com> 2011-05-30 15:15:12 CDT ---
This is correct behavior.  byvals with vectors in them are given 16-byte
alignment.  Use of movaps is always valid and preferred if the code generator
can know that the pointer is 16-byte aligned.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 15:18:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 15:18:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10052] New: Comparision of pointer to Objective-C
 object with C++0x nullptr fails to compile
Message-ID: <bug-10052-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10052

           Summary: Comparision of pointer to Objective-C object with
                    C++0x nullptr fails to compile
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following Objective-C++ program fails to compile:

@interface NSOpenGLPixelFormat
{
}
@end

int main(int, char**)
{
    NSOpenGLPixelFormat* p = 0;
    if (p == nullptr)
        ;
}


This results in:

$ clang -x objective-c++ -std=c++0x clang.cpp
clang.cpp:9:8: error: invalid operands to binary expression
      ('NSOpenGLPixelFormat *' and 'nullptr_t')
        if (p == nullptr)


After replacing "nullptr" with "0L", the code compiles as expected.

My clang version:

$ clang --version
clang version 3.0 (trunk 131897)
Target: x86_64-apple-darwin10.7.0
Thread model: posix


C.f. the thread on cfe-dev, starting at
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-May/015350.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 May 30 15:21:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 15:21:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9826] [MC] Should use symbolic register names in
 the .cfi_* directives
In-Reply-To: <bug-9826-206@http.llvm.org/bugs/>
References: <bug-9826-206@http.llvm.org/bugs/>
Message-ID: <20110530202108.713B62A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9826

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-05-30 15:21:07 CDT ---
Fixed in 132317.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 17:14:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 17:14:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10053] New: [QoI] diagnostic in case of two-stage
 name lookup-related errors could be better
Message-ID: <bug-10053-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10053

           Summary: [QoI] diagnostic in case of two-stage name
                    lookup-related errors could be better
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


A recurring problem when people try to switch from g++ to clang is errors due
to two-stage name lookup:

  http://clang.llvm.org/compatibility.html#dep_lookup

It would be great if we could produce awesome diagnostics for such cases, by
repeating the unqualified (non-ADL) name lookup and checking whether any
newly-found functions are viable:

  my_file.cpp:2:10: error: use of undeclared identifier 'Multiply'
    return Multiply(x, x);
           ^

  my_file.cpp:10:3: note: in instantiation of function template specialization
'Squared<int>' requested here
    Squared(5);
    ^

  my_file.cpp:5:5: note: viable function not candidate: declared after template
was defined, and not in an associated namespace
  int Multiply(int x, int y) {
      ^

Further, this new note should probably suppress the existing 'candidate
function not viable' notes, since we can be confident that this newly-declared
function is the one the user meant to call. That would trim this huge
diagnostic down to just one error and three useful notes:

  http://paste.kde.org/76543/

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon May 30 21:02:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 30 May 2011 21:02:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10054] New: LLVM should transform bit test branch
 into select for better backend codegen
Message-ID: <bug-10054-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10054

           Summary: LLVM should transform bit test branch into select for
                    better backend codegen
           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: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu


take the following for example:
unsigned sb_4(unsigned x, unsigned y) {
        if ((x & y) == 0) {
                x &= ~y;
        }
        return x;
}

this ends up turning into:
define i32 @sb_4(i32 %x, i32 %y) nounwind uwtable readnone ssp {
entry:
  %and = and i32 %y, %x
  %cmp = icmp eq i32 %and, 0
  br i1 %cmp, label %if.then, label %if.end

if.then:                                          ; preds = %entry
  %neg = xor i32 %y, -1
  %and4 = and i32 %neg, %x
  br label %if.end

if.end:                                           ; preds = %if.then, %entry
  %x.addr.0 = phi i32 [ %and4, %if.then ], [ %x, %entry ]
  ret i32 %x.addr.0
}

however, I think it should turn into:
define i32 @sb_5(i32 %x, i32 %y) nounwind uwtable readnone ssp {
entry:
  %and = and i32 %x, %y
  %neg = xor i32 %y, -1
  %and2 = and i32 %x, %neg
  %cmp = icmp eq i32 %and, 0
  %and2.x = select i1 %cmp, i32 %and2, i32 %x
  ret i32 %and2.x
}

on x86-64 this results in nicer codegen because there is no branch, just a cmov

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 31 03:38:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 31 May 2011 03:38:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10055] New: ~1 in 100 crash in
 PCH/chain-late-anonymous-namespace.cpp
Message-ID: <bug-10055-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10055

           Summary: ~1 in 100 crash in
                    PCH/chain-late-anonymous-namespace.cpp
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


Sitting at my console running that test over and over, I was able to reproduce
this on try #117:

$ make test TESTSUITE=PCH/chain-late-anonymous-namespace.cpp
make[1]: Entering directory `/home/nicholas/llvm-commit/tools/clang/test'
Making Clang 'lit.site.cfg' file...
Making Clang 'Unit/lit.site.cfg' file...
--- Running clang tests for x86_64-unknown-linux-gnu ---
lit.py: lit.cfg:143: note: using clang:
'/home/nicholas/llvm-commit/Debug+Asserts/bin/clang'
                       -- Testing: 1 tests, 2 threads --                        
FAIL: Clang :: PCH/chain-late-anonymous-namespace.cpp (1 of 1)
******************** TEST 'Clang :: PCH/chain-late-anonymous-namespace.cpp'
FAILED ********************
Script:
--
/home/nicholas/llvm-commit/Debug+Asserts/bin/clang -cc1 -include
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
-include
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
-fsyntax-only
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
/home/nicholas/llvm-commit/Debug+Asserts/bin/clang -cc1 -chain-include
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
-chain-include
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
-fsyntax-only
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
--
Exit Code: 134
Command Output (stderr):
--
clang: raw_ostream.cpp:323: void llvm::raw_ostream::copy_to_buffer(const char*,
size_t): Assertion `Size <= size_t(OutBufEnd - OutBufCur) && "Buffer overrun!"'
failed.
0  clang 0x0a183e1e
1  clang 0x0a183bab
2        0xffffe400 __kernel_sigreturn + 0
Stack dump:
0.      Program arguments: /home/nicholas/llvm-commit/Debug+Asserts/bin/clang
-cc1 -chain-include
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
-chain-include
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
-fsyntax-only
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp 
1.      <eof> parser at end of file
/home/nicholas/llvm-commit/tools/clang/test/PCH/Output/chain-late-anonymous-namespace.cpp.script:
line 2: 27686 Aborted                
/home/nicholas/llvm-commit/Debug+Asserts/bin/clang -cc1 -chain-include
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
-chain-include
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
-fsyntax-only
/home/nicholas/llvm-commit/tools/clang/test/PCH/chain-late-anonymous-namespace.cpp
--

********************
Testing Time: 0.05s
********************
Failing Tests (1):
    Clang :: PCH/chain-late-anonymous-namespace.cpp

  Unexpected Failures: 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/nicholas/llvm-commit/tools/clang/test'
make: *** [test] Error 2

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 31 03:48:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 31 May 2011 03:48:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10020] fail to codegen virtual function in template
In-Reply-To: <bug-10020-206@http.llvm.org/bugs/>
References: <bug-10020-206@http.llvm.org/bugs/>
Message-ID: <20110531084854.42E592A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10020

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nicholas at mxc.ca
         Resolution|                            |FIXED
         AssignedTo|unassignedclangbugs at nondot. |nicholas at mxc.ca
                   |org                         |

--- Comment #3 from Nick Lewycky <nicholas at mxc.ca> 2011-05-31 03:48:53 CDT ---
Hah, then I guess I get to fix it!

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110530/042350.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 May 31 07:25:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 31 May 2011 07:25:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10048] llc 2.9 doesn't care of packed attribute to
 generate code for x86 target
In-Reply-To: <bug-10048-206@http.llvm.org/bugs/>
References: <bug-10048-206@http.llvm.org/bugs/>
Message-ID: <20110531122520.5A60A2A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10048

seb <babslachem at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #7 from seb <babslachem at gmail.com> 2011-05-31 07:25:19 CDT ---
Hi,

Your explanation make sense, now I've modified code as follows:

%struct.sType = type < { < 4 x float >, < 4 x float >, < 4 x float > } >
%struct.sType.alt = type < { [12 x float] } >
@A = common global < 4 x float > zeroinitializer
@B = common global < 4 x float > zeroinitializer
@C = common global < 4 x float > zeroinitializer
define void @bar(%struct.sType* byval %s) {
L.entry:
    %0 = bitcast %struct.sType* %s to < 4 x float >*
    %1 = load < 4 x float >* %0, align 1
    store < 4 x float > %1, < 4 x float >* @A, align 1
    %2 = bitcast %struct.sType* %s to < 4 x float >*
    %3 = load < 4 x float >* %2, align 1
    store < 4 x float > %3, < 4 x float >* @B, align 1
    %4 = bitcast %struct.sType* %s to < 4 x float >*
    %5 = load < 4 x float >* %4, align 1
    store < 4 x float > %5, < 4 x float >* @C, align 1
    ret void
}

define void @foo1(%struct.sType.alt* byval %x) {
L.entry:
    %0 = bitcast %struct.sType.alt* %x to %struct.sType*
    call void  @bar (%struct.sType* byval %0)
    ret void
}

generated code for foo1 is:

foo1:                                   # @foo1
.Leh_func_begin1:
# BB#0:                                 # %L.entry
    subl    $60, %esp
.Ltmp1:
    movaps  96(%esp), %xmm0
    movaps  %xmm0, 32(%esp)
    movaps  64(%esp), %xmm0
    movaps  80(%esp), %xmm1
    movaps  %xmm1, 16(%esp)
    movaps  %xmm0, (%esp)
    calll   bar
    addl    $60, %esp
    ret


I would have expected that copy from struct.sTYpe.alt to struct.sType uses
movups for loads instead of movaps, since struct.sType.alt is not supposed to
be aligned on a 16 byte boundary. Why movaps are generated for loading ?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 31 07:33:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 31 May 2011 07:33:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10048] llc 2.9 doesn't care of packed attribute to
 generate code for x86 target
In-Reply-To: <bug-10048-206@http.llvm.org/bugs/>
References: <bug-10048-206@http.llvm.org/bugs/>
Message-ID: <20110531123334.359242A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10048

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #8 from Duncan Sands <baldrick at free.fr> 2011-05-31 07:33:33 CDT ---
But %x is still aligned on a 16 byte boundary!  After all, the function's stack
is 16 byte aligned, and %x is in essence the first stack variable.  Try
changing
the prototype of foo1 as follows to ensure that %x is not the first thing on
the
stack:

define void @foo1(i8* byval %z, %struct.sType.alt* byval %x) {

All the movaps 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 May 31 08:00:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 31 May 2011 08:00:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10048] llc 2.9 doesn't care of packed attribute to
 generate code for x86 target
In-Reply-To: <bug-10048-206@http.llvm.org/bugs/>
References: <bug-10048-206@http.llvm.org/bugs/>
Message-ID: <20110531130008.4AE332A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10048

seb <babslachem at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #11 from seb <babslachem at gmail.com> 2011-05-31 08:00:07 CDT ---
Duncan,

Tried  your change and it is still generating movaps for foo1.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 31 11:09:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 31 May 2011 11:09:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10037] Poor code generated for whole-vector shifts
In-Reply-To: <bug-10037-206@http.llvm.org/bugs/>
References: <bug-10037-206@http.llvm.org/bugs/>
Message-ID: <20110531160948.A7A8C2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10037

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #7 from Duncan Sands <baldrick at free.fr> 2011-05-31 11:09:48 CDT ---
The dragonegg frontend no longer produces this construct.  Instead it directly
produces a vector shuffle.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 31 15:52:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 31 May 2011 15:52:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10056] New: PassManager segfault when trying to
 schedule custom Immutable Pass
Message-ID: <bug-10056-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10056

           Summary: PassManager segfault when trying to schedule custom
                    Immutable Pass
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: michael at lunarg.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6667)
 --> (http://llvm.org/bugs/attachment.cgi?id=6667)
Skeleton code

I'm in a debug build with assertions turned on for llvm-2.9, and I get a
segfault whenever I try to schedule one of my own immutable passes in a pass
manager. It seems that one of the passes that I'm scheduling (IndVarSimplify)
attempts to ask for TargetData if it's available (I'm not providing it), and
that's when it segfaults. If I split that pass into it's own pass manager, then
everything works fine. Attached is skeleton code that exposes this. Below is
some stack traces for the run functions in Run.h and Run.cpp

RunDoesntWork stacktrace:
#0  0x083af2ed in std::vector<llvm::PassInfo const*,
std::allocator<llvm::PassInfo const*> >::begin (this=0x10) at
/usr/include/c++/4.4/bits/stl_vector.h:435
#1  0x083a6fb8 in llvm::PMTopLevelManager::findAnalysisPass (this=0x87e1d9c,
AID=0x85f0f60) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:673
#2  0x083a6d21 in llvm::PMTopLevelManager::schedulePass (this=0x87e1d9c,
P=0x867dff0) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:614
#3  0x083ad434 in llvm::PassManagerImpl::add (this=0x87e1cc8, P=0x867dff0) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:396
#4  0x083ab475 in llvm::PassManager::addImpl (this=0xbffe9568, P=0x867dff0) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1659
#5  0x083ab59a in llvm::PassManager::add (this=0xbffe9568, P=0x867dff0) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1672
#6  0x0809a257 in RunDoesntWork (module=0x85fdeb8) at
../LunarGLASS/Passes/Immutable/tmp/Run.cpp:34
#7  0x0808fcd3 in gla::PrivateManager::runLLVMOptimizations1 (this=0x85fd5c0)
at ../LunarGLASS/TopToBottom.cpp:272
#8  0x0808f42f in gla::PrivateManager::translateTopToBottom (this=0x85fd5c0) at
../LunarGLASS/TopToBottom.cpp:69
#9  0x08107097 in main (argc=2, argv=0xbffff184) at main.cpp:394

RunDoesntWork2 stacktrace:
#0  0x083af399 in std::vector<llvm::PassInfo const*,
std::allocator<llvm::PassInfo const*> >::begin (this=0x10) at
/usr/include/c++/4.4/bits/stl_vector.h:435
#1  0x083a7064 in llvm::PMTopLevelManager::findAnalysisPass (this=0x87e1d9c,
AID=0x85f0f30) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:673
#2  0x083a8baa in llvm::PMDataManager::findAnalysisPass (this=0x8604e90,
AID=0x85f0f30, SearchParent=true) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1062
#3  0x083a97a5 in llvm::AnalysisResolver::getAnalysisIfAvailable
(this=0x87d9110, ID=0x85f0f30, dir=true) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1215
#4  0x08121b7e in llvm::Pass::getAnalysisIfAvailable<llvm::TargetData>
(this=0x87e1e70) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/include/llvm/PassAnalysisSupport.h:181
#5  0x082b6ad7 in llvm::ScalarEvolution::runOnFunction (this=0x87e1e70, F=...)
at /home/michael/LunarGLASS/LLVM/llvm-2.9/lib/Analysis/ScalarEvolution.cpp:5965
#6  0x083aa90f in llvm::FPPassManager::runOnFunction (this=0x8604e80, F=...) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1483
#7  0x083aaac9 in llvm::FPPassManager::runOnModule (this=0x8604e80, M=...) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1503
#8  0x083aadb4 in llvm::MPPassManager::runOnModule (this=0x8619f18, M=...) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1557
#9  0x083ab26a in llvm::PassManagerImpl::run (this=0x87e1cc8, M=...) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1638
#10 0x083ab75b in llvm::PassManager::run (this=0xbffe9568, M=...) at
/home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1682
#11 0x0809a314 in RunDoesntWork2 (module=0x85fdeb8) at
../LunarGLASS/Passes/Immutable/tmp/Run.cpp:52
#12 0x0808fcd3 in gla::PrivateManager::runLLVMOptimizations1 (this=0x85fd5c0)
at ../LunarGLASS/TopToBottom.cpp:272
#13 0x0808f42f in gla::PrivateManager::translateTopToBottom (this=0x85fd5c0) at
../LunarGLASS/TopToBottom.cpp:69
#14 0x08107143 in main (argc=2, argv=0xbffff184) at main.cpp:394

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue May 31 22:53:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 31 May 2011 22:53:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10057] New: leftover temporaries in function
Message-ID: <bug-10057-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10057

           Summary: leftover temporaries in function
           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


This tiny program causes a crash in clang++ -fsyntax-only:

  struct Empty {};

  struct Exciting {
    ~Exciting();
    void operator=(const Empty&) const;
  };

  template <class VarType>
  void Test(const VarType& value) {
    return Exciting() = Empty() << value;
  }

This is the assertion:

clang: SemaDecl.cpp:6380: clang::Decl*
clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool):
Assertion `ExprTemporaries.empty() && "Leftover temporaries in function"'
failed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.