From bugzilla-daemon at cs.uiuc.edu  Fri Jun  1 12:00:56 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jun 2007 12:00:56 -0500
Subject: [LLVMbugs] [Bug 320] [passmanager] Infinite loop when a transitive
	pass requires a transitive pass
Message-ID: <200706011700.l51H0uno010213@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-01 12:00 -------
New PassManager does not go into infinite loop (at compile time as well as runtime) when I apply 
following patch to Hello example.

Index: Hello.cpp                                                                                                                                            
===============================================================
====                                                                                         
RCS file: /var/cvs/llvm/llvm/lib/Transforms/Hello/Hello.cpp,v                                                                                               
retrieving revision 1.18                                                                                                                                    
diff -r1.18 Hello.cpp                                                                                                                                       
42a43,59                                                                                                                                                    
>   struct Hello1 : public FunctionPass {                                                                                                                   
>     static char ID; // Pass identification, replacement for typeid                                                                                        
>     Hello1() : FunctionPass((intptr_t)&ID) {}                                                                                                             
>                                                                                                                                                           
>     virtual bool runOnFunction(Function &F) {                                                                                                             
>       HelloCounter++;                                                                                                                                     
>       std::string fname = F.getName();                                                                                                                    
>       EscapeString(fname);                                                                                                                                
>       cerr << "Hello1: " << fname << "\n";                                                                                                                
>       return false;                                                                                                                                       
>     }                                                                                                                                                     
>   };                                                                                                                                                      
>                                                                                                                                                           
>   char Hello1::ID = 0;                                                                                                                                    
>   RegisterPass<Hello1> X1("hello1", "Hello1 World Pass");                                                                                                 
>                                                                                                                                                           
>                                                                                                                                                           
57a75                                                                                                                                                       
>       AU.addRequiredTransitive<Hello>();                                                                                                                  
58a77                                                                                                                                                       
>       const std::vector<AnalysisID> &IDs = AU.getRequiredTransitiveSet();                                                                                 




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun  1 14:00:37 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jun 2007 14:00:37 -0500
Subject: [LLVMbugs] [Bug 1486] NEW: ExitValue of intepreter left in broken
	state at interpreter construction
Message-ID: <200706011900.l51J0bh0014062@zion.cs.uiuc.edu>

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

           Summary: ExitValue of intepreter left in broken state at
                    interpreter construction
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Interpreter
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: cfr at adobe.com


Interpreter::Interpreter(Module *M) : ExecutionEngine(M), TD(M) {
	  memset(&ExitValue, 0, sizeof(ExitValue));   <-----
	...
	}

The problem with this line is that it leaves the APInt value within 
ExitValue in a broken state (bit width cannot be zero).  If you run a 
function with no return value through the interpreter it will crash as 
the ExitValue is passed out of the interpreter's run function as it 
gets to the APInt copy constructor.

This problem is easily reproducable with by running a void function through 
the interpeter.  I've seen this repro both on Mac OSX and Vista.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun  1 17:11:30 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jun 2007 17:11:30 -0500
Subject: [LLVMbugs] [Bug 1487] NEW: opt crash in indvars pass
Message-ID: <200706012211.l51MBUWd019001@zion.cs.uiuc.edu>

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

           Summary: opt crash in indvars pass
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lauro.venancio at gmail.com


laurov at laurov-desktop:~$ opt bugpoint-reduced-simplified.bc -indvars -o tmp.bc
opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x86674fe]
opt((anonymous namespace)::SignalHandler(int)+0x112)[0x86677c4]
[0xffffe420]
opt(llvm::ETNode::DominatedBySlow(llvm::ETNode*)+0x18)[0x8419a4e]
opt(llvm::ETForestBase::dominates(llvm::BasicBlock*,
llvm::BasicBlock*)+0xba)[0x8419b0e]
opt[0x8629c2d]
opt[0x862a715]
opt(llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visitAdd(llvm::BinaryOperator&)+0x18)[0x862eea8]
opt(llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visit(llvm::Instruction&)+0xe6)[0x862f6d0]
opt(void llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visit<llvm::ilist_iterator<llvm::Instruction>
>(llvm::ilist_iterator<llvm::Instruction>,
llvm::ilist_iterator<llvm::Instruction>)+0x45)[0x862fae3]
opt(llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visit(llvm::BasicBlock&)+0x5e)[0x862fb5a]
opt(void llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visit<llvm::ilist_iterator<llvm::BasicBlock>
>(llvm::ilist_iterator<llvm::BasicBlock>,
llvm::ilist_iterator<llvm::BasicBlock>)+0x45)[0x862fba5]
opt(llvm::InstVisitor<(anonymous namespace)::Verifier,
void>::visit(llvm::Function&)+0x5e)[0x862fdc2]
opt[0x862fe11]
opt(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x13a)[0x8601f1c]
opt(llvm::FPPassManager::runOnModule(llvm::Module&)+0x6e)[0x86020e4]
opt(llvm::MPPassManager::runOnModule(llvm::Module&)+0x11d)[0x8601bbd]
opt(llvm::PassManagerImpl::run(llvm::Module&)+0x6e)[0x8601d8a]
opt(llvm::PassManager::run(llvm::Module&)+0x1a)[0x8601ddc]
opt(main+0xa10)[0x83964e6]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7c6cebc]
opt(realloc+0x71)[0x8388711]
Segmentation fault (core dumped)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun  1 17:16:54 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jun 2007 17:16:54 -0500
Subject: [LLVMbugs] [Bug 1002] LICM doesn't update alias sets correctly
Message-ID: <200706012216.l51MGs9S019205@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-01 17:16 -------
Thanks. Applied.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070528/050154.html

Andrew, I am closing this. Feel free to open if it does not fix the problem you were seeing.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun  1 17:25:20 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jun 2007 17:25:20 -0500
Subject: [LLVMbugs] [Bug 1486] ExitValue of intepreter left in broken state
	at interpreter construction
Message-ID: <200706012225.l51MPKn5019541@zion.cs.uiuc.edu>

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

rspencer at reidspencer.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |miscompilation, regression
         Resolution|                            |FIXED



------- Additional Comments From rspencer at reidspencer.com  2007-06-01 17:25 -------
Fix patches here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070528/050155.html





------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun  2 20:35:20 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 2 Jun 2007 20:35:20 -0500
Subject: [LLVMbugs] [Bug 1488] NEW: bithacks: optimize code that counts bits
Message-ID: <200706030135.l531ZKiT003276@zion.cs.uiuc.edu>

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

           Summary: bithacks: optimize code that counts bits
           Product: libraries
           Version: trunk
          Platform: All
               URL: http://graphics.stanford.edu/~seander/bithacks.html#Coun
                    tBitsSetKernighan
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


The common idiom for counting the number of bits set can be optimized.

unsigned countbits_slow(unsigned v)
{
  unsigned c;
  for (c = 0; v; v >>= 1)
  {
    c += v & 1;
  }
  return c;
}

This can be rewritten as such:

unsigned countbits_fast(unsigned v)
{
  unsigned c;
  for (c = 0; v; c++)
  {
    v &= v - 1; // clear the least significant bit set
  }
  return c;
}

There are other ways to rewrite the bit-counting code, but they involve other
tradeoffs such as constant arrays. Also, the naive method may be written such
that it starts with the high bit or low bit for performance, if the programmer
happens to know about the distribution of the bits in advance. countbits_fast
will equal or outperform either implementation.

With stock GCC, countbits_slow has a 63% longer run-time in a tight loop, while
with llvm-gcc, countbits_slow has a 45% longer run-time. (Sadly, llvm-gcc is
slower than GCC at either function on x86 Linux, but that's another bug.)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun  2 20:40:35 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 2 Jun 2007 20:40:35 -0500
Subject: [LLVMbugs] [Bug 1489] NEW: miscompilation of a simple c file (X86)
Message-ID: <200706030140.l531eZ1X003514@zion.cs.uiuc.edu>

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

           Summary: miscompilation of a simple c file (X86)
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lauro.venancio at gmail.com


llvm-gcc is miscompiling the following c code:

------------------------------------------------------

#define _ISOC9X_SOURCE  1
#include <math.h>
int main( void ) { return (lrintf(3.999f) > 0)?0:1; }

-------------------------------------------------------

laurov at laurov-laptop:/tmp$ gcc test.c -o test -lm
laurov at laurov-laptop:/tmp$ ./test
laurov at laurov-laptop:/tmp$ echo $?
0
laurov at laurov-laptop:/tmp$ llvm-gcc test.c -o test -lm
laurov at laurov-laptop:/tmp$ ./test
laurov at laurov-laptop:/tmp$ echo $?
1

To reproduce this bug with llc must be used "llc -disable-fp-elim -fast -mcpu=i486".



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun  2 22:14:31 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 2 Jun 2007 22:14:31 -0500
Subject: [LLVMbugs] [Bug 1490] NEW: assertion failed compiling ffmpeg (X86
	and CBackend)
Message-ID: <200706030314.l533EVVC006585@zion.cs.uiuc.edu>

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

           Summary: assertion failed compiling ffmpeg (X86 and CBackend)
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lauro.venancio at gmail.com


laurov at laurov-laptop:/tmp$ llc bugpoint-reduced-simplified.bc 
llc: /home/laurov/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3529:
void llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallInst&): Assertion `0
&& "matching constraints for memory operands unimp"' failed.
llc((anonymous namespace)::PrintStackTrace()+0x1a)[0x8952106]
llc((anonymous namespace)::SignalHandler(int)+0x112)[0x89523cc]
[0xffffe420]
/lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb7c97641]
/lib/tls/i686/cmov/libc.so.6(__assert_fail+0xfb)[0xb7c8f43b]
llc(llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallInst&)+0xfa0)[0x86d2568]
llc(llvm::SelectionDAGLowering::visitCall(llvm::CallInst&)+0x7c5)[0x86d69e9]
llc(llvm::SelectionDAGLowering::visit(unsigned int, llvm::User&)+0x416)[0x86f86a6]
llc(llvm::SelectionDAGLowering::visit(llvm::Instruction&)+0x28)[0x86f8760]
llc(llvm::SelectionDAGISel::BuildSelectionDAG(llvm::SelectionDAG&,
llvm::BasicBlock*, std::vector<std::pair<llvm::MachineInstr*, unsigned int>,
std::allocator<std::pair<llvm::MachineInstr*, unsigned int> > >&,
llvm::FunctionLoweringInfo&)+0x14a)[0x86ddde0]
llc(llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)+0xa0)[0x86de880]
llc(llvm::SelectionDAGISel::runOnFunction(llvm::Function&)+0x11f)[0x86e04bb]
llc[0x859f313]
llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x13a)[0x88ecdec]
llc(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0x6e)[0x88ed070]
llc(llvm::FunctionPassManager::run(llvm::Function&)+0x88)[0x88ed1be]
llc(main+0x97d)[0x8428a8d]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7c81ebc]
llc[0x84271e1]
Cancelado (core dumped)

------------------------------------------------------------------------------

laurov at laurov-laptop:/tmp$ llc -march=c bugpoint-reduced-simplified.bc 
llc: /home/laurov/llvm/llvm/lib/Target/CBackend/CBackend.cpp:2722:
void<unnamed>::CWriter::visitInlineAsm(llvm::CallInst&): Assertion
`I->Codes.size() == 1 && "Too many asm constraint codes to handle"' failed.
llc((anonymous namespace)::PrintStackTrace()+0x1a)[0x8952106]
llc((anonymous namespace)::SignalHandler(int)+0x112)[0x89523cc]
[0xffffe420]
/lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb7cd8641]
/lib/tls/i686/cmov/libc.so.6(__assert_fail+0xfb)[0xb7cd043b]
llc((anonymous
namespace)::CWriter::visitInlineAsm(llvm::CallInst&)+0x1b8)[0x8659f94]
llc((anonymous namespace)::CWriter::visitCallInst(llvm::CallInst&)+0x2b)[0x865281d]
llc(llvm::InstVisitor<(anonymous namespace)::CWriter,
void>::visitCall(llvm::CallInst&)+0x18)[0x8664c34]
llc(llvm::InstVisitor<(anonymous namespace)::CWriter,
void>::visit(llvm::Instruction&)+0x422)[0x8665058]
llc((anonymous
namespace)::CWriter::printBasicBlock(llvm::BasicBlock*)+0x204)[0x86544ec]
llc((anonymous namespace)::CWriter::printFunction(llvm::Function&)+0x6ef)[0x8654dc5]
llc((anonymous namespace)::CWriter::runOnFunction(llvm::Function&)+0x4f)[0x8665139]
llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x13a)[0x88ecdec]
llc(llvm::FPPassManager::runOnModule(llvm::Module&)+0x6e)[0x88ecfb4]
llc(llvm::MPPassManager::runOnModule(llvm::Module&)+0x11d)[0x88eca8d]
llc(llvm::PassManagerImpl::run(llvm::Module&)+0x6e)[0x88ecc5a]
llc(llvm::PassManager::run(llvm::Module&)+0x1a)[0x88eccac]
llc(main+0x5c0)[0x84286d0]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7cc2ebc]
llc[0x84271e1]
Cancelado (core dumped)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Jun  3 07:45:53 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jun 2007 07:45:53 -0500
Subject: [LLVMbugs] [Bug 1491] NEW: Type mismatch in module with global
	std::map
Message-ID: <200706031245.l53CjrdU015501@zion.cs.uiuc.edu>

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

           Summary: Type mismatch in module with global std::map
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: maarten at treewalker.org


I compile this program to LLVM bytecode:

#include <map>
std::map<int, int> someMap;

Using this command line:

$ llvm-g++ -O2 --emit-llvm -o mapbug.bc -c mapbug.cc

Then when I try to use the resulting bytecode module, the LLVM tools will 
complain about it being invalid. For example:

$ llvm-link -f -o mapbug.linked.bc mapbug.bc
Global variable initializer type does not match global variable type!
"struct.std::map<int,int,std::less<int>,std::allocator<std::pair<const int, 
int> > >"* @someMap
Broken module found, compilation aborted!

This problem disappears if I remove "-O2" or replace it by "-O0".

I'm using LLVM 2.0 and its g++ front-end, compiled from source with GCC 4.1.3.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Jun  3 11:38:00 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jun 2007 11:38:00 -0500
Subject: [LLVMbugs] [Bug 1492] NEW: Wrong arguments for main() trigger
	assert in lli
Message-ID: <200706031638.l53Gc0kQ021634@zion.cs.uiuc.edu>

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

           Summary: Wrong arguments for main() trigger assert in lli
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: maarten at treewalker.org


This program contains a bug: (argv and argc are swapped)

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

I compile it to bytecode like this:

$ llvm-g++ --emit-llvm -o wrongmain.bc -c wrongmain.cc

And then run it in the LLVM interpreter like this:

$ lli wrongmain.bc

Which triggers the following assertion:

lli: Instructions.cpp:210: void llvm::CallInst::init(llvm::Value*, 
llvm::Value* const*, unsigned int): Assertion `(i >= FTy->getNumParams() || 
FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a 
bad signature!"' failed.
lli((anonymous namespace)::PrintStackTrace()+0x19)[0x847fcb9]
/lib/libc.so.6(abort+0x101)[0xb7ce7801]
/lib/libc.so.6(__assert_fail+0xfb)[0xb7cdf7bb]
lli(llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned 
int)+0x181)[0x841adb1]
Aborted

I'm using LLVM 2.0 and its g++ front-end, compiled from source with GCC 4.1.3.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Jun  3 11:44:29 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jun 2007 11:44:29 -0500
Subject: [LLVMbugs] [Bug 1492] Wrong arguments for main() trigger assert in
	lli
Message-ID: <200706031644.l53GiT2l021817@zion.cs.uiuc.edu>

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

asl at math.spbu.ru changed:

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



------- Additional Comments From asl at math.spbu.ru  2007-06-03 11:44 -------
This is not a bug. lli cannot know, whether arguments are swapped, dropped, etc.
It supports all 3 types of main():

- int main(void)
- int main(argc, argv)
- int main(argc, argv, envp)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Jun  3 13:17:47 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jun 2007 13:17:47 -0500
Subject: [LLVMbugs] [Bug 1492] Wrong arguments for main() trigger assert in
	lli
Message-ID: <200706031817.l53IHlv9024373@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2007-06-03 13:17 -------
I agree with Maarten.  lli should check that the types are right and refuse to run the program if not.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Jun  3 14:02:08 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jun 2007 14:02:08 -0500
Subject: [LLVMbugs] [Bug 1493] NEW: Segfault in produced native executable
Message-ID: <200706031902.l53J28Qk025953@zion.cs.uiuc.edu>

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

           Summary: Segfault in produced native executable
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: maarten at treewalker.org


See attached sources and build+test script.

The bug occurs only when compiling to bytecode and then linking the bytecode 
into a single executable. When I use llvm-g++ to compile each C++ source to 
native object files and link those, the executable runs fine.

Running the bytecode of the executable in lli also produces a segfault.

The std::map, although unused in the code, is essential for the segfault to 
occur. Also, the segfault only occurs when I use two source files: when I put 
this same code in a single C++ source file, it runs fine.

The std::map being part of the problem looks similar to bug 1491, but not 
exactly the same:
- this bug occurs when running the native executable, no errors while linking
- this bug also occurs without -O2

I'm using LLVM 2.0 and its g++ front-end, compiled from source with GCC 4.1.3.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Jun  3 14:22:12 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jun 2007 14:22:12 -0500
Subject: [LLVMbugs] [Bug 1492] Wrong arguments for main() trigger assert in
	lli
Message-ID: <200706031922.l53JMCGb026583@zion.cs.uiuc.edu>

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

asl at math.spbu.ru changed:

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



------- Additional Comments From asl at math.spbu.ru  2007-06-03 14:22 -------
Fixed in

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070528/050179.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070528/050180.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Jun  3 15:50:03 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jun 2007 15:50:03 -0500
Subject: [LLVMbugs] [Bug 1494] NEW: Linking fails when using "static const
	double" field
Message-ID: <200706032050.l53Ko30q028560@zion.cs.uiuc.edu>

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

           Summary: Linking fails when using "static const double" field
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: maarten at treewalker.org


When compiling the following program:

===
template <unsigned N>
class C {
public:
	static const double INVERSE = 1.0 / N;
};

double getInverse()
{
	return C<14>::INVERSE;
}

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

// Without this, linking fails on INVERSE.
//template class C<14>;
===

With the command line:

$ llvm-g++ -o inverse inverse.cc

I get this error message:

/tmp/cc4LClWF.o: In function `getInverse()':
(.text+0xd): undefined reference to `C<14u>::INVERSE'
collect2: ld returned 1 exit status

This error goes away when forcing template instantiation by enabling the 
commented out line at the end.

In the non-LLVM GCC this compiles and links just fine. However, when compiling 
with "-pedantic" it tells you:

inverse.cc:4: error: ISO C++ forbids initialization of member 
constant ???INVERSE??? of non-integral type ???const double???

So according to the current spec this entire construct is not allowed. But it 
would be practical to be compatible with GCC's behaviour, to make more 
existing code compile to LLVM.

I'm using LLVM 2.0 and its g++ front-end, compiled from source with GCC 4.1.3.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sun Jun  3 16:36:50 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jun 2007 16:36:50 -0500
Subject: [LLVMbugs] [Bug 1494] Linking fails when using "static const
	double" field
Message-ID: <200706032136.l53LaoF5029719@zion.cs.uiuc.edu>

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

asl at math.spbu.ru changed:

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



------- Additional Comments From asl at math.spbu.ru  2007-06-03 16:36 -------
Maarten, it seems, that you've hit one of the most reported gcc's not-bugs :).
Even if GCC accepts it, it doesn't mean, that it's a bug.

Please refer to:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13051
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14404
(Thanks to Andrew Pinski to dig that)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun  4 15:40:51 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jun 2007 15:40:51 -0500
Subject: [LLVMbugs] [Bug 1495] NEW: another assertion failed compiling
	ffmpeg (X86)
Message-ID: <200706042040.l54KepTV007848@zion.cs.uiuc.edu>

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

           Summary: another assertion failed compiling ffmpeg (X86)
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lauro.venancio at gmail.com


laurov at laurov-desktop:~/ffmpeg/libavcodec$ llc bugpoint-reduced-simplified.bc 
llc: /home/laurov/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:732:
llvm::SDOperand llvm::SelectionDAGLowering::getValue(const llvm::Value*):
Assertion `InReg && "Value not in map!"' failed.
llc((anonymous namespace)::PrintStackTrace()+0x1a)[0x8951f92]
llc((anonymous namespace)::SignalHandler(int)+0x112)[0x8952258]
[0xffffe420]
/lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb7ca6641]
/lib/tls/i686/cmov/libc.so.6(__assert_fail+0xfb)[0xb7c9e43b]
llc(llvm::SelectionDAGLowering::getValue(llvm::Value const*)+0xb8d)[0x86cd9d3]
llc(llvm::SelectionDAGLowering::visitScalarBinary(llvm::User&, unsigned
int)+0x31)[0x86d8cff]
llc(llvm::SelectionDAGLowering::visitAdd(llvm::User&)+0x8c)[0x86f7912]
llc(llvm::SelectionDAGLowering::visit(unsigned int, llvm::User&)+0xda)[0x86f7bde]
llc(llvm::SelectionDAGLowering::visit(llvm::Instruction&)+0x28)[0x86f7fd4]
llc(llvm::SelectionDAGISel::BuildSelectionDAG(llvm::SelectionDAG&,
llvm::BasicBlock*, std::vector<std::pair<llvm::MachineInstr*, unsigned int>,
std::allocator<std::pair<llvm::MachineInstr*, unsigned int> > >&,
llvm::FunctionLoweringInfo&)+0x14a)[0x86dd654]
llc(llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)+0xa0)[0x86de0f4]
llc(llvm::SelectionDAGISel::runOnFunction(llvm::Function&)+0x11f)[0x86dfd2f]
llc[0x859eba3]
llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x13a)[0x88ecae8]
llc(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0x6e)[0x88ecd6c]
llc(llvm::FunctionPassManager::run(llvm::Function&)+0x88)[0x88eceba]
llc(main+0x97d)[0x842831d]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7c90ebc]
llc[0x8426a71]
Aborted (core dumped)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun  4 16:11:45 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jun 2007 16:11:45 -0500
Subject: [LLVMbugs] [Bug 1496] NEW: tail merging badness with exception
	handling
Message-ID: <200706042111.l54LBj0t008775@zion.cs.uiuc.edu>

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

           Summary: tail merging badness with exception handling
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr


If I compile the testcase like this
$ llc -enable-eh report.bc
then block invcont131 is removed (this
is the first block to be removed).  It
should not be removed.  If I turn off
tail merging then it is no longer removed.

Here is a valid path through the function:

entry -> bb -> cond_next44 -> cond_true80 ->
cond_next109 -> invcont131 -> cond_next618 (returns)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun  4 17:25:07 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jun 2007 17:25:07 -0500
Subject: [LLVMbugs] [Bug 1491] globalopt crash for packed structs
Message-ID: <200706042225.l54MP7xN011067@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|new bugs                    |Interprocedural
                   |                            |Optimizations
           Keywords|                            |compile-fail
         OS/Version|Linux                       |All
            Product|new-bugs                    |libraries
           Platform|PC                          |All
         Resolution|                            |FIXED
            Summary|Type mismatch in module with|globalopt crash for packed
                   |global std::map             |structs
   Target Milestone|---                         |2.1
            Version|unspecified                 |2.0



------- Additional Comments From sabre at nondot.org  2007-06-04 17:25 -------
Fixed, patch here: 
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050206.html

Testcase here: GlobalOpt/2007-06-04-PackedStruct.ll

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun  4 18:13:36 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jun 2007 18:13:36 -0500
Subject: [LLVMbugs] [Bug 1490] assertion failed compiling ffmpeg (X86)
Message-ID: <200706042313.l54NDaWd012346@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2007-06-04 18:13 -------
This is a dup of Bug 1133 (X86 BE) and Bug 802 (CBE)

-Chris

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



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun  4 18:55:45 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jun 2007 18:55:45 -0500
Subject: [LLVMbugs] [Bug 1496] tail merging badness with exception handling
Message-ID: <200706042355.l54NtjN2013344@zion.cs.uiuc.edu>

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

dalej at apple.com changed:

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



------- Additional Comments From dalej at apple.com  2007-06-04 18:55 -------
Indeed tail merging wasn't right for landing pads.  Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050215.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050217.html




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun  4 19:58:19 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jun 2007 19:58:19 -0500
Subject: [LLVMbugs] [Bug 1497] NEW: pass manager crash
Message-ID: <200706050058.l550wJ2V015062@zion.cs.uiuc.edu>

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

           Summary: pass manager crash
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


$ llvm-as /dev/null -o t.bc
$ opt -analyze -print-cfg-only t.bc


/Volumes/Projects/cvs/llvm/include/llvm/PassManagers.h:229: failed assertion `0 && "Unable to 
handle Pass that requires lower level Analysis pass"'
0   opt                                 0x0015039d 
_ZN40_GLOBAL__N_Signals.cpp_00000000_D6FCAF0915PrintStackTraceEv + 35
1   opt                                 0x00150743 
_ZN40_GLOBAL__N_Signals.cpp_00000000_D6FCAF0913SignalHandlerEi + 323
2   libSystem.B.dylib                   0x91b201a1 _sigtramp + 55
3   ???                                 0xffffffff 0x0 + 4294967295
4   libSystem.B.dylib                   0x91b284d1 raise + 26
5   libSystem.B.dylib                   0x91b4eb73 abort + 84
6   opt                                 0x001564ad lt_dlloader_find + 203
7   opt                                 0x002a2bb9 
_ZN4llvm13PMDataManager25addLowerLevelRequiredPassEPNS_4PassES2_ + 55
8   opt                                 0x001202ef _ZN4llvm13PMDataManager3addEPNS_4PassEb + 823
9   opt                                 0x00120903 
_ZN4llvm12FunctionPass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeE + 505
10  opt                                 0x002abc9d _ZN4llvm15PassManagerImpl15addTopLevelPassEPNS_4PassE + 
247
11  opt                                 0x0011df12 _ZN4llvm17PMTopLevelManager12schedulePassEPNS_4PassE + 
332
12  opt                                 0x002a642f _ZN4llvm15PassManagerImpl3addEPNS_4PassE + 27
13  opt                                 0x0011df3e _ZN4llvm11PassManager3addEPNS_4PassE + 26
14  opt                                 0x0000354e main + 2174
15  opt                                 0x0000192c start + 252
16  opt                                 0x00001859 start + 41



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun  4 21:10:10 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jun 2007 21:10:10 -0500
Subject: [LLVMbugs] [Bug 1498] NEW: Extremely slow optimization for large
	arrays
Message-ID: <200706050210.l552AAPo017269@zion.cs.uiuc.edu>

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

           Summary: Extremely slow optimization for large arrays
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: maarten at treewalker.org


I compile this test program:

===
class Storage {
	unsigned data[0x2000];
};

void f(Storage);

void g() {
	Storage storage;
	f(storage);
}
===

With this command line:

$ time llvm-g++ -O1 --emit-llvm -o slowopt.o -c slowopt.cc

It takes about 20 seconds to compile on my machine (2GHz P4). However, 
with -O0, it compiles in less than a tenth of a second.

The size of the array is crucial in this: doubling the size makes compilation 
take four times as long. So it seems part of the optimization algorithm has a 
running time quadratic in the array size.

I'm using LLVM 2.0, with the fix for bug 1491 applied, and its g++ front-end, 
compiled from source with GCC 4.1.3.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun  5 01:03:46 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jun 2007 01:03:46 -0500
Subject: [LLVMbugs] [Bug 1498] Extremely slow optimization for large arrays
Message-ID: <200706050603.l5563kRl023445@zion.cs.uiuc.edu>

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

baldrick at free.fr changed:

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



------- Additional Comments From baldrick at free.fr  2007-06-05 01:03 -------


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



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun  5 15:27:14 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jun 2007 15:27:14 -0500
Subject: [LLVMbugs] [Bug 1497] pass manager crash
Message-ID: <200706052027.l55KRELU023067@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-05 15:25 -------
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050240.html

Fixed.





------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun  5 16:25:09 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jun 2007 16:25:09 -0500
Subject: [LLVMbugs] [Bug 1499] NEW: Instruction Combining misoptimization
Message-ID: <200706052125.l55LP9Sk026016@zion.cs.uiuc.edu>

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

           Summary: Instruction Combining misoptimization
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lauro.venancio at gmail.com


Instruction Combining is wrongly optimizing the following code:

        %tmp30 = load i64* %tmp10               ; <i64> [#uses=1]
        %.cast = zext i32 63 to i64             ; <i64> [#uses=1]
        %tmp31 = ashr i64 %tmp30, %.cast                ; <i64> [#uses=1]
        %tmp3132 = trunc i64 %tmp31 to i32              ; <i32> [#uses=1]
        %tmp33 = or i32 %tmp3132, 1             ; <i32> [#uses=1]
        store i32 %tmp33, i32* %tmp9
        %tmp34 = load i32* %tmp9                ; <i32> [#uses=1]
        store i32 %tmp34, i32* %retval
        br label %return.exitStub

to 
        store i32 -1, i32* %tmp9
        store i32 -1, i32* %retval
        ret void



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun  5 20:20:29 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jun 2007 20:20:29 -0500
Subject: [LLVMbugs] [Bug 1500] NEW: File produced by opt cannot be
	disassembled with llvm-dis
Message-ID: <200706060120.l561KTfd032027@zion.cs.uiuc.edu>

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

           Summary: File produced by opt cannot be disassembled with llvm-
                    dis
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Bitcode Writer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: resistor at mac.com


The attached file was produced by opt (without disabling the verifier), and will not disassemble with llvm-
dis.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun  5 20:24:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jun 2007 20:24:41 -0500
Subject: [LLVMbugs] [Bug 1495] LSR can produce invalid SSA when value reuse
	occurs
Message-ID: <200706060124.l561OfG3032312@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|new bugs                    |Scalar Optimizations
           Keywords|                            |compile-fail
            Product|new-bugs                    |libraries
         Resolution|                            |FIXED
            Summary|another assertion failed    |LSR can produce invalid SSA
                   |compiling ffmpeg (X86)      |when value reuse occurs
   Target Milestone|---                         |2.1
            Version|unspecified                 |1.9



------- Additional Comments From sabre at nondot.org  2007-06-05 20:24 -------
Fixed.  Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050261.html

Testcase here: CodeGen/X86/2007-06-05-LSR-Dominator.ll

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun  5 23:14:28 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jun 2007 23:14:28 -0500
Subject: [LLVMbugs] [Bug 1487] opt crash in indvars pass
Message-ID: <200706060414.l564ESVm003910@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

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



------- Additional Comments From nicholas at mxc.ca  2007-06-05 23:14 -------
Fixed. Patches here: 

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050264.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050266.html

Testcase here: Transforms/IndVarsSimplify/2007-06-06-DeleteDanglesPtr.ll




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun  6 11:59:40 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jun 2007 11:59:40 -0500
Subject: [LLVMbugs] [Bug 1500] File produced by opt cannot be disassembled
	with llvm-dis
Message-ID: <200706061659.l56Gxe8n030229@zion.cs.uiuc.edu>

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

resistor at mac.com changed:

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



------- Additional Comments From resistor at mac.com  2007-06-06 11:59 -------
That's strange... it seems to work now.

Oh well, probably just user error.  Closed.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun  6 12:12:20 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jun 2007 12:12:20 -0500
Subject: [LLVMbugs] [Bug 1499] Instruction Combining misoptimization
Message-ID: <200706061712.l56HCKxQ030568@zion.cs.uiuc.edu>

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

lauro.venancio at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1
            Version|trunk                       |2.0



------- Additional Comments From lauro.venancio at gmail.com  2007-06-06 12:12 -------
Fixed.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050287.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050288.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun  6 13:10:52 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jun 2007 13:10:52 -0500
Subject: [LLVMbugs] [Bug 1501] NEW: Critical loop backedges are split and
	copies placed on the edge
Message-ID: <200706061810.l56IAqL5031981@zion.cs.uiuc.edu>

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

           Summary: Critical loop backedges are split and copies placed on
                    the edge
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


It looks like backedges in loops sometimes get split and phi copies end up in them or something.  This 
is badness:

extern double _Complex conj (double _Complex __z) __attribute__ ((__nothrow__));

#define DELAY 2000000
#define SIZE 1024

void
zgemm (int k, _Complex *a, _Complex *b, _Complex *c)
{
  int i, l;
  _Complex double temp = (0.0,0.0);

  for (i=0; i < DELAY; i++)
    for (l=0; l < k; l++)
      temp = temp + conj (a[l]) * b[l];
  c[0] = temp;
}

_Complex c;

int test (void) {
  _Complex a[SIZE];
  _Complex b[SIZE];
  zgemm (SIZE, a, b, &c);
  return 0;
}

This currently compiles the inner loop into:

LBB2_2: #bb11.us
        movsd (%esp,%ecx), %xmm2
        movsd 16384(%esp,%ecx), %xmm3
        movapd %xmm3, %xmm4
        mulsd %xmm2, %xmm4
        movsd 16392(%esp,%ecx), %xmm5
        mulsd %xmm5, %xmm2
        movsd 8(%esp,%ecx), %xmm6
        mulsd %xmm6, %xmm3
        subsd %xmm2, %xmm3
        addsd %xmm0, %xmm3
        mulsd %xmm5, %xmm6
        addsd %xmm6, %xmm4
        addsd %xmm1, %xmm4
        incl %edx
        addl $16, %ecx
        cmpl $1023, %edx
        jle LBB2_6      #bb11.us.bb11.us_crit_edge
...
LBB2_6: #bb11.us.bb11.us_crit_edge
        movapd %xmm3, %xmm0
        movapd %xmm4, %xmm1
        jmp LBB2_2      #bb11.us

Ick.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun  6 15:53:32 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jun 2007 15:53:32 -0500
Subject: [LLVMbugs] [Bug 1493] internalize zapping global constructors
Message-ID: <200706062053.l56KrWsY004813@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|new bugs                    |Interprocedural
                   |                            |Optimizations
           Keywords|                            |miscompilation
            Product|new-bugs                    |libraries
         Resolution|                            |FIXED
            Summary|Segfault in produced native |internalize zapping global
                   |executable                  |constructors
   Target Milestone|---                         |2.1
            Version|unspecified                 |1.9



------- Additional Comments From sabre at nondot.org  2007-06-06 15:53 -------
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050302.html

This was due to some legacy code that was used to support llvm-gcc3.  The easiest thing to do is to zap it 
entirely.  Thanks for the report and the nice reduced testcase!

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun  6 15:55:58 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jun 2007 15:55:58 -0500
Subject: [LLVMbugs] [Bug 1502] NEW: live-interval trouble with exception
	handling
Message-ID: <200706062055.l56KtwHu004943@zion.cs.uiuc.edu>

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

           Summary: live-interval trouble with exception handling
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr


Logically speaking, the exception register and exception selector register
should be marked as live-in on landing pads.  (Currently they are marked
live-in on the block containing the EXCEPTIONADDR/EHSELECTION selections,
which seems wrong).  I wrote a patch to fix this, but then live-intervals
blows up on several testcases in the testsuite, for example:
(1) CodeGen/Generic/2007-04-14-EHSelectorCrash.ll.  Here the problem seems
to be that there is no landing pad but there is a EHSELECTION instruction.
So the exception selector register is used without being marked live-in
anywhere.
(2) CodeGen/Generic/2007-06-06-CriticalEdgeLandingPad.ll.  Here the registers
are not used in the landing pad itself (they are used in a sucessor).
Live-intervals doesn't seem to like having registers marked as live-in without
actually being used in that machine basic block.

Could a live-intervals expert please take a look?



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun  6 16:36:39 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jun 2007 16:36:39 -0500
Subject: [LLVMbugs] [Bug 1482] Compiling generated .c file (by llc) on Linux
	X86 fails
Message-ID: <200706062136.l56Ladbj006169@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2007-06-06 16:36 -------
GCC rejects that code as well.  In clobber lists, you have to say that you clobber "esi" or "edi", not S or D.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun  6 23:18:43 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jun 2007 23:18:43 -0500
Subject: [LLVMbugs] [Bug 1503] NEW: passmanager problem
Message-ID: <200706070418.l574IhZi016014@zion.cs.uiuc.edu>

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

           Summary: passmanager problem
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


Something's either wrong with the passmanager or with one of the passes:

$ llvm/Debug/bin/opt b.bc -loops -domtree -licm -lcssa -disable-output

opt: /home/nicholas/llvm/include/llvm/PassAnalysisSupport.h:193: AnalysisType&
llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType =
llvm::DominatorTree]: Assertion `ResultPass && "getAnalysis*() called on an
analysis that was not " "'required' by pass!"' failed.
llvm/Debug/bin/opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x864190a]
llvm/Debug/bin/opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8641bd0]
[0xffffe500]
Aborted



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Jun  7 16:08:46 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 7 Jun 2007 16:08:46 -0500
Subject: [LLVMbugs] [Bug 1489] X86: when SSE1 isn't available,
	f32 arguments are incorrectly passes as f64
Message-ID: <200706072108.l57L8k5W016191@zion.cs.uiuc.edu>

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

dalej at apple.com changed:

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



------- Additional Comments From dalej at apple.com  2007-06-07 16:08 -------
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050332.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun  8 13:40:02 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Jun 2007 13:40:02 -0500
Subject: [LLVMbugs] [Bug 1422] Landing pad wrongly removed
Message-ID: <200706081840.l58Ie2LX026040@zion.cs.uiuc.edu>

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

baldrick at free.fr changed:

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



------- Additional Comments From baldrick at free.fr  2007-06-08 13:40 -------
Fixed by:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070528/050117.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050276.html

Testcase:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050275.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun  9 16:25:00 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 9 Jun 2007 16:25:00 -0500
Subject: [LLVMbugs] [Bug 1504] NEW: DebugInfo tests fail with 'file not
	found'
Message-ID: <200706092125.l59LP0Fs004907@zion.cs.uiuc.edu>

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

           Summary: DebugInfo tests fail with 'file not found'
           Product: Test Suite
           Version: 2.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Programs Tests
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dhein at acm.org


I'm running the DebugInfo tests in the source tree and I get a FAIL from five of
the tests -- they complain about 'file not found', but it might just be a
corrupted shell command (see the example output at the end of this note).  The
tool chain seems to be working fine, so I'm not sure why these tests fail.

I'm running on a PowerPC with OS X 10.4.9 and XCode 2.4.  I'm using an optimized
version of llvm, and I'm using a version of the front end that I built from the
source. 

Most of the other tests work ... the only other tests that fail are some of the
CodeGen tests fail because I built llvm with only the powerpc target and so the
x86 and ARM and so on fail because of missing target support.

Here is an example of the first couple failures (output from running "make
TESTSUITE=DebugInfo":

Running /Users/davehein/llvm/llvm2.0/src/llvm-2.0/test/DebugInfo/dg.exp ...
FAIL:
/Users/davehein/llvm/llvm2.0/src/llvm-2.0/test/DebugInfo/2006-11-06-StackTrace.cpp
Failed with posix(ENOENT,no such file or directory) at line 1
while running:  -emit-llvm -S -O0 -g
/Users/davehein/llvm/llvm2.0/src/llvm-2.0/test/DebugInfo/2006-11-06-StackTrace.cpp
-o - | llvm-as | llc --disable-fp-elim -o Output/2006-11-06-StackTrace.cpp.tmp.s -f
couldn't execute "-emit-llvm": no such file or directory
FAIL:
/Users/davehein/llvm/llvm2.0/src/llvm-2.0/test/DebugInfo/2006-11-20-GlobalSymbols.cpp
for PR1013
Failed with posix(ENOENT,no such file or directory) at line 1
while running:  -emit-llvm -O0 -g -c
/Users/davehein/llvm/llvm2.0/src/llvm-2.0/test/DebugInfo/2006-11-20-GlobalSymbols.cpp
couldn't execute "-emit-llvm": no such file or directory

--
Dave Hein



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun  9 16:44:34 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 9 Jun 2007 16:44:34 -0500
Subject: [LLVMbugs] [Bug 1504] DebugInfo tests fail with 'file not found'
Message-ID: <200706092144.l59LiYep005415@zion.cs.uiuc.edu>

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

asl at math.spbu.ru changed:

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



------- Additional Comments From asl at math.spbu.ru  2007-06-09 16:44 -------
Dave,

you have to reconfigure your llvm installation with '-with-llvmgccdir' option in
order to specify, where llvm-gcc is.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 11 14:24:55 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jun 2007 14:24:55 -0500
Subject: [LLVMbugs] [Bug 1505] NEW: wrong floating point code with mcpu=i686
	(i.e. no sse)
Message-ID: <200706111924.l5BJOt8L003196@zion.cs.uiuc.edu>

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

           Summary: wrong floating point code with mcpu=i686 (i.e. no sse)
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr


The easiest way to see the problem is with lli (see below), but the same
happens if you build with llc.  If sse extensions are turned off (by using
-mcpu=i686) then wrong code is produced.  This is not a floating point
precision problem: if you run under valgrind then it reports the use of an
uninitialized value at each failure point.  If compiled with sse extensions
(which on my machine is what you get if you don't specify the cpu) then
valgrind does not complain and the program works correctly.  I tried to
reduce the testcase but bugpoint didn't come up with anything sensible,
and any changes that make it substantially smaller seem to make the problem
go away...

$ lli tc.bc

,.,. C34003A ACATS 2.5 07-06-11 21:17:30
---- C34003A CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED
                (IMPLICITLY) FOR DERIVED FLOATING POINT TYPES.
==== C34003A PASSED ============================.
$ lli -mcpu=i686 tc.bc

,.,. C34003A ACATS 2.5 07-06-11 21:17:53
---- C34003A CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED
                (IMPLICITLY) FOR DERIVED FLOATING POINT TYPES.
   * C34003A INCORRECT :=.
   * C34003A INCORRECT QUALIFICATION.
   * C34003A INCORRECT SELF CONVERSION.
   * C34003A INCORRECT CONVERSION TO PARENT.
   * C34003A INCORRECT CONVERSION TO INTEGER.
   * C34003A INCORRECT CONVERSION TO FLOAT.
   * C34003A INCORRECT CONVERSION TO FIXED.
   * C34003A INCORRECT IMPLICIT CONVERSION.
   * C34003A INCORRECT REAL LITERAL.
   * C34003A INCORRECT =.
   * C34003A INCORRECT <=.
   * C34003A INCORRECT >=.
   * C34003A INCORRECT UNARY +.
   * C34003A INCORRECT UNARY -.
   * C34003A INCORRECT ABS.
   * C34003A INCORRECT BINARY +.
   * C34003A INCORRECT BINARY -.
   * C34003A INCORRECT *.
   * C34003A INCORRECT /.
   * C34003A INCORRECT **.
**** C34003A FAILED ****************************.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 11 17:14:17 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jun 2007 17:14:17 -0500
Subject: [LLVMbugs] [Bug 1299] Incorrect use of RIP Relative to access
	globals on x86_64
Message-ID: <200706112214.l5BMEHnU006586@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2007-06-11 17:14 -------
we don't have a testcase to repro this.  Please reopen when information to reproduce is available.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 11 20:02:49 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jun 2007 20:02:49 -0500
Subject: [LLVMbugs] [Bug 1409] Should merge etforest into domtree
Message-ID: <200706120102.l5C12nM5010134@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-11 20:02 -------

....
....
....
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050418.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050419.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050420.html

Done. Now only pred simplifier uses ETForest. Once that pass is updated we can remove ETForest from 
source tree.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun 12 04:41:47 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jun 2007 04:41:47 -0500
Subject: [LLVMbugs] [Bug 1506] NEW: JIT not caching stub code built for
	functions with "non-common" argument patterns
Message-ID: <200706120941.l5C9fl0G031410@zion.cs.uiuc.edu>

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

           Summary: JIT not caching stub code built for functions with "non-
                    common" argument patterns
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Target-Independent JIT
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: duraid at octopus.com.au
                CC: letz at grame.fr


A user points out the following thinko in the JIT when dispatching code that is
not of a common argument type (i.e. one where a stub has to be created.)

What we *should* be doing is caching the code generated for the function that is
being passed to runFunction(). If the function passed is of a common type such
that a stub doesn't need to be created, this works fine. However, if the
function needs to be called through a stub, the *stub* gets cached but the
actual user function is not.

As he put it on IRC:

"you have runFunction(f) ==> [make stub ==> runFunction (Stub(f))], then
*Stub(f)* is cached yes
but then runFunction(f) again Stub(f) is there but runFunction cannot know that"



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun 12 11:37:54 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jun 2007 11:37:54 -0500
Subject: [LLVMbugs] [Bug 1507] NEW: Break predicate simplifier free from
	ETForest
Message-ID: <200706121637.l5CGbsXj009557@zion.cs.uiuc.edu>

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

           Summary: Break predicate simplifier free from ETForest
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dpatel at apple.com
                CC: nicholas at mxc.ca


Predicate simplification pass is the last one to use ETForest and ETNode. Update this pass to not use these 
data structure so that we can remove them from source tree.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun 12 11:57:48 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jun 2007 11:57:48 -0500
Subject: [LLVMbugs] [Bug 1506] JIT not caching stub code built for functions
	with "non-common" argument patterns
Message-ID: <200706121657.l5CGvmbi010010@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2007-06-12 11:57 -------
FWIW, I don't think this is a coding bug, though it is probably a documentation bug.

You almost never want to call runFunction.  Instead, just do something like this:


void (*FPtr)(int, float, int*) = (void (*FPtr)(int, float, int*))EE->getPointerToFunction(F);

Then do:

FPtr(1, 4.0f, NULL);

or whatever.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 13 11:47:54 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jun 2007 11:47:54 -0500
Subject: [LLVMbugs] [Bug 1508] NEW: typeinfos and personality functions
	should be attached to the invoke
Message-ID: <200706131647.l5DGls0F002833@zion.cs.uiuc.edu>

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

           Summary: typeinfos and personality functions should be attached
                    to the invoke
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr


Exception handling typeinfos and personality functions are currently
supplied by an intrinsic (eh.selector or eh.filter) that is placed in
the invoke landing pad.  This is a flawed scheme: the optimizers can move
the intrinsic out of the landing pad.  How then to know to which landing
pad the typeinfos and personality should be applied?  This is exactly what
happens to the intrinsics in landing pad unwind871 in
test/CodeGen/Generic/2007-06-06-CriticalEdgeLandingPad.ll
[The optimizers insert a critical edge basic block; this becomes
the landing pad, with the intrinsics in the successor.  You can tell
that the type infos got lost because the exception action for the
invoke in cond_true870 is 1, i.e. cleanups only, rather than 5].
This PR is for discussion of how best to fix this issue.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun 15 00:03:08 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jun 2007 00:03:08 -0500
Subject: [LLVMbugs] [Bug 1509] NEW: reg spiller madness (SSE)
Message-ID: <200706150503.l5F538OQ029506@zion.cs.uiuc.edu>

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

           Summary: reg spiller madness (SSE)
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: duraid at octopus.com.au


Attaching (big) testcase..



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun 15 00:21:57 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jun 2007 00:21:57 -0500
Subject: [LLVMbugs] [Bug 1510] NEW: xor-inferring optimizations would be nice
Message-ID: <200706150521.l5F5LvAR029922@zion.cs.uiuc.edu>

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

           Summary: xor-inferring optimizations would be nice
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: duraid at octopus.com.au


we don't currently infer that

~( ~(a|b) | (a&b) ) -> a^b

and similar, e.g. ~(~a & ~b) & ~(a&b) -> a^b



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun 15 00:29:14 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jun 2007 00:29:14 -0500
Subject: [LLVMbugs] [Bug 1509] reg spiller madness (SSE)
Message-ID: <200706150529.l5F5TEuf030150@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2007-06-15 00:29 -------
The spiller isn't going crazy, duraid just needs more caffeine.  If he runs the instcombine and uses this 
patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050487.html

The attached testcase shrinks from 32K lines to 30K lines of x86-64 asm.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun 15 01:26:22 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jun 2007 01:26:22 -0500
Subject: [LLVMbugs] [Bug 1510] xor-inferring optimizations would be nice
Message-ID: <200706150626.l5F6QMpl031904@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |code-quality
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1



------- Additional Comments From sabre at nondot.org  2007-06-15 01:26 -------
Implemented.  There are many patches to this, the primary ones being:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050487.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050489.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050495.html

Testcase here: Transforms/InstCombine/and-or-not.ll

This shrunk Duraid's nasty example from 32K lines of x86-64 .s file to 23k lines.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun 15 02:29:15 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jun 2007 02:29:15 -0500
Subject: [LLVMbugs] [Bug 1511] NEW: Overloading functions by vector type
	produces silent failure or ICE
Message-ID: <200706150729.l5F7TFbe010000@zion.cs.uiuc.edu>

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

           Summary: Overloading functions by vector type produces silent
                    failure or ICE
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: christopher.lamb at gmail.com


The following code will either ICE in the FE (my latest FE from CVS) or silently omit the first overloaded 
function (web submission form).

typedef float float2 __attribute__ ((vector_size (8)));
typedef float float4 __attribute__ ((vector_size (16)));

float4 test(float4 a) { return a; }
float2 test(float2 a) { return a; }



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun 15 04:46:11 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jun 2007 04:46:11 -0500
Subject: [LLVMbugs] [Bug 1512] NEW: sse code regalloc/spillfill problems
	(only 2 registers used for 280 instructions)
Message-ID: <200706150946.l5F9kBlB013896@zion.cs.uiuc.edu>

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

           Summary: sse code regalloc/spillfill problems (only 2 registers
                    used for 280 instructions)
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: duraid at octopus.com.au


Consider the following x86-64 sse code (emitted after the fixes to pr1509 and 1510)

0x00000001040a2796:     movaps %xmm0,15744(%rsp)  <- store xmm0 here (it gets clobbered)
0x00000001040a279e:     movaps 15536(%rsp),%xmm0
0x00000001040a27a6:     xorps  %xmm2,%xmm0
0x00000001040a27a9:     movaps %xmm0,15536(%rsp)
0x00000001040a27b1:     movaps 15296(%rsp),%xmm0
0x00000001040a27b9:     orps   15536(%rsp),%xmm0
0x00000001040a27c1:     movaps %xmm0,15296(%rsp)  <- store new xmm0 here for a second
0x00000001040a27c9:     movaps 15744(%rsp),%xmm0  <- restore the old xmm0
0x00000001040a27d1:     andps  15296(%rsp),%xmm0  <- only to and the new xmm0 with it
0x00000001040a27d9:     movaps %xmm0,15744(%rsp)  <- and store it where the old one was
0x00000001040a27e1:     movaps 15792(%rsp),%xmm0  <- before clobbering xmm0 again
// note: sp+15296 and +15536 are never referenced again.
// (15792 and 15744 *are* used again)

At first glance, this code looks like it was produced under severe register pressure, e.g. xmm0 is spilled 
spilled/filled just so it can be used to AND a single value computed immediately prior.

If there wasn't any register pressure (i.e. if you could use registers other than xmm0 and xmm2), you 
could rewrite the above fragment as simply:

movaps %xmm0,15744(%rsp)
movaps 15536(%rsp),%xmm1
xorps  %xmm2,%xmm1
movaps 15296(%rsp),%xmm3
orps   %xmm1,%xmm3
andps  %xmm3,%xmm0
movaps %xmm0,15744(%rsp)
movaps 15792(%rsp),%xmm0

..saving 3 instructions, but also being able to raise some loads and/or issue some instructions in 
parallel. (In the fragment above, everything is seralized through xmm0, and it doesn't look like any kind 
of renaming breaks these dependencies for SSE registers.) The only catch is that this new code would 
clobber anything in xmm1 or xmm3.

And that's where this bug repot comes in. The fragment up top is actually insn #14527 in a block of 
23745. However, the first time a register that *isn't* xmm0 or xmm2 appears is actually 123 
instructions earlier. And the first time a register not used in the above fragment gets referenced after 
the fragment is 145 instructions later. So basically, the above code is sitting in a window of ~280 
instructions where the only registers used are xmm0 and xmm2. Eek!

An improvement would be to have regs xmm1 and xmm3 spilled *once*, at the top of the "window", 
filled at the bottom, and code such as the stuff I've written above in between.

Not sure what the root cause of this behaviour is.

I will try and distill a smaller test case showing this, but it's hard to see this kind of "hysteresis" in very 
small cases. (It just looks like regalloc is doing a normal job.) Right now, pr1509's testcase shows the 
same problem.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun 15 10:24:39 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jun 2007 10:24:39 -0500
Subject: [LLVMbugs] [Bug 1513] NEW: Wrong assignmend of attributes
Message-ID: <200706151524.l5FFOdoH021473@zion.cs.uiuc.edu>

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

           Summary: Wrong assignmend of attributes
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com


consider the function

struct long s{
long a;
long b;
}

void f(struct s, char *, char);

In x86_64 the struct s is passed in registers, so the llvm type should be

f(i64, i64, i8 *, i8 sext)

The problem is that in TypeConvert::ConvertFunctionType, the Idx is only
incremented by one when passing by the first (C) argument. Because of this the
llvm type generated is invalid:

f(i64, i64, i8 * sext, i8)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Fri Jun 15 23:55:03 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jun 2007 23:55:03 -0500
Subject: [LLVMbugs] [Bug 1514] NEW: llc options don't have descriptions in
	"-help" output
Message-ID: <200706160455.l5G4t3Iu008010@zion.cs.uiuc.edu>

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

           Summary: llc options don't have descriptions in "-help" output
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: isanbard at gmail.com


These options don't have descriptions in the help:

  -enable-ppc-preinc           - 
  -print-isel-input            - 
  -print-lsr-output            -



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 16 04:15:12 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jun 2007 04:15:12 -0500
Subject: [LLVMbugs] [Bug 1515] NEW: llvm2cpp generates incorrect code when
	-funcname parameter is used.
Message-ID: <200706160915.l5G9FCQj022610@zion.cs.uiuc.edu>

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

           Summary: llvm2cpp generates incorrect code when -funcname
                    parameter is used.
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: letz at grame.fr


When llvm2cpp is used to generated a program *and* -funcname parameter is used, the generated 
code is incorrect:  

llvm2cpp -f   -funcname=LLVMBackend template.bc gives:

Module* LLVMBackend();

int main(int argc, char**argv) {
  Module* Mod = makeLLVMModule();
  verifyModule(*Mod, PrintMessageAction);
  std::cerr.flush();
  std::cout.flush();
  PassManager PM;
  PM.add(new PrintModulePass(&llvm::cout));
  PM.run(*Mod);
  return 0;
}
...

main call the "generic" makeLLVMModule() function where LLVMBackend() should be used instead. The 
following patch for current CVS fix the problem:


? cppwritter.patch
Index: tools/llvm2cpp/CppWriter.cpp
===============================================================
====
RCS file: /var/cvs/llvm/llvm/tools/llvm2cpp/CppWriter.cpp,v
retrieving revision 1.49
diff -u -r1.49 CppWriter.cpp
--- tools/llvm2cpp/CppWriter.cpp	5 Jun 2007 05:28:26 -0000
	1.49
+++ tools/llvm2cpp/CppWriter.cpp	16 Jun 2007 09:03:50 -0000
@@ -1690,7 +1690,7 @@
   Out << "using namespace llvm;\n\n";
   Out << "Module* " << fname << "();\n\n";
   Out << "int main(int argc, char**argv) {\n";
-  Out << "  Module* Mod = makeLLVMModule();\n";
+  Out << "  Module* Mod =" << fname << "();\n";
   Out << "  verifyModule(*Mod, PrintMessageAction);\n";
   Out << "  std::cerr.flush();\n";
   Out << "  std::cout.flush();\n";



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 16 09:12:45 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jun 2007 09:12:45 -0500
Subject: [LLVMbugs] [Bug 1516] NEW: llvm2cpp generates incorrect code when
	-gen-function -funcname -for are used
Message-ID: <200706161412.l5GECjHD029122@zion.cs.uiuc.edu>

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

           Summary: llvm2cpp generates incorrect code when -gen-function -
                    funcname  -for are used
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: letz at grame.fr


llvm2cpp  generates incorrcect code in the following case:

1) compile the following function to substitute_bug.bc:

#include <stdio.h>

extern "C" void NewMarker1()
{
	printf("NewMarker1 \n");
}

2) lvm2cpp  -f  -gen-function -funcname=makeNewMarker1 -for=NewMarker1 substitute_bug.bc -o 
substitute_bug.bc.cpp

// Generated by llvm2cpp - DO NOT MODIFY!


Function* makeNewMarker1(Module *mod) {

// Type Definitions
std::vector<const Type*>FuncTy_0_args;
ParamAttrsList *FuncTy_0_PAL = 0;
FunctionType* FuncTy_0 = FunctionType::get(
  /*Result=*/Type::VoidTy,
  /*Params=*/FuncTy_0_args,
  /*isVarArg=*/false,
  /*ParamAttrs=*/FuncTy_0_PAL);

PointerType* PointerTy_1 = PointerType::get(IntegerType::get(8));

ArrayType* ArrayTy_3 = ArrayType::get(IntegerType::get(8), 12);

PointerType* PointerTy_2 = PointerType::get(ArrayTy_3);

std::vector<const Type*>FuncTy_5_args;
FuncTy_5_args.push_back(PointerTy_1);
ParamAttrsList *FuncTy_5_PAL = 0;
FunctionType* FuncTy_5 = FunctionType::get(
  /*Result=*/IntegerType::get(32),
  /*Params=*/FuncTy_5_args,
  /*isVarArg=*/false,
  /*ParamAttrs=*/FuncTy_5_PAL);

PointerType* PointerTy_4 = PointerType::get(FuncTy_5);


// Function Declarations

Function* func_puts = new Function(
  /*Type=*/FuncTy_5,
  /*Linkage=*/GlobalValue::ExternalLinkage,
  /*Name=*/"puts", mod); // (external, no body)
func_puts->setCallingConv(CallingConv::C);

// Global Variable Declarations

GlobalVariable* gvar_array__str = new GlobalVariable(
/*Type=*/ArrayTy_3,
/*isConstant=*/true,
/*Linkage=*/GlobalValue::InternalLinkage,
/*Initializer=*/0, // has initializer, specified below
/*Name=*/".str",
mod);

// Constant Definitions
Constant* const_int32_6 = Constant::getNullValue(IntegerType::get(32));

// Global Variable Definitions
gvar_array__str->setInitializer(const_array_7);

Function* func_NewMarker1 = new Function(
  /*Type=*/FuncTy_0,
  /*Linkage=*/GlobalValue::ExternalLinkage,
  /*Name=*/"NewMarker1", mod); 
func_NewMarker1->setCallingConv(CallingConv::C);

BasicBlock* label_entry = new BasicBlock("entry",func_NewMarker1,0);
BasicBlock* label_return = new BasicBlock("return",func_NewMarker1,0);

// Block entry (label_entry)
std::vector<Value*> ptr_tmp_indices;
ptr_tmp_indices.push_back(const_int32_6);
ptr_tmp_indices.push_back(const_int32_6);
Instruction* ptr_tmp = new GetElementPtrInst(gvar_array__str, &ptr_tmp_indices[0], 2, "tmp", 
label_entry);
CallInst* int32_tmp1 = new CallInst(func_puts, ptr_tmp, "tmp1", label_entry);
int32_tmp1->setCallingConv(CallingConv::C);
int32_tmp1->setTailCall(false);
new BranchInst(label_return, label_entry);

// Block return (label_return)
new ReturnInst(label_return);
return func_NewMarker1;
}
 
The "const_array_7" constant definition is missing from the generated code.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 16 11:18:40 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jun 2007 11:18:40 -0500
Subject: [LLVMbugs] [Bug 1515] llvm2cpp generates incorrect code when
	-funcname parameter is used.
Message-ID: <200706161618.l5GGIeXj031623@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|new bugs                    |llvm2cpp
            Product|new-bugs                    |tools
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1
            Version|unspecified                 |2.0



------- Additional Comments From nicholas at mxc.ca  2007-06-16 11:18 -------
Fixed. Thanks for the patch!

Testcase here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050537.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 16 11:31:24 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jun 2007 11:31:24 -0500
Subject: [LLVMbugs] [Bug 1517] NEW: llvm2cpp generates incorrect code
Message-ID: <200706161631.l5GGVOwZ031920@zion.cs.uiuc.edu>

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

           Summary: llvm2cpp generates incorrect code
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: letz at grame.fr


#include <stdio.h>

extern "C" void NewMarker1()
{
	printf("NewMarker1 \n");
	printf("NewMarker1 \n");
}

llvm2cpp  -f  -gen-function -funcname=makeNewMarker1 -for=NewMarker1 test.bc -o substitute_bug. 
test.cpp  produces



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 16 15:35:44 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jun 2007 15:35:44 -0500
Subject: [LLVMbugs] [Bug 1516] llvm2cpp generates incorrect code when
	-gen-function -funcname -for are used
Message-ID: <200706162035.l5GKZi3H004408@zion.cs.uiuc.edu>

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

rspencer at reidspencer.com changed:

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



------- Additional Comments From rspencer at reidspencer.com  2007-06-16 15:35 -------
Fixed with this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050540.html

Note: -gen-function is not supposed to generate a stand alone function. It is,
however, supposed to generate something that will recreate everything needed by
a single function.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 16 15:49:50 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jun 2007 15:49:50 -0500
Subject: [LLVMbugs] [Bug 1517] llvm2cpp generates incorrect code
Message-ID: <200706162049.l5GKnoCX004765@zion.cs.uiuc.edu>

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

rspencer at reidspencer.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|new bugs                    |llvm2cpp
            Product|new-bugs                    |tools
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1
            Version|unspecified                 |1.0



------- Additional Comments From rspencer at reidspencer.com  2007-06-16 15:49 -------
Fixed with this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070611/050541.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 18 11:55:54 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jun 2007 11:55:54 -0500
Subject: [LLVMbugs] [Bug 1518] NEW: Alias analysis chaining doesn't work
Message-ID: <200706181655.l5IGtsA0024092@zion.cs.uiuc.edu>

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

           Summary: Alias analysis chaining doesn't work
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru


Consider attached source file. This is our custom alias analysis helper for
llvm-qemu. It's easy to check, that it can be ImmutablePass, not ModulePass. 

But this approach doesn't work (simple change ModulePass to ImmutablePass
everywhere plus runModule() -> initializePass()).

Also (maybe unrealted) - the name of BasicAA is reported wrong at -time-passes,
the name of its superclass is reported instead (NoAA)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 18 13:24:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jun 2007 13:24:41 -0500
Subject: [LLVMbugs] [Bug 1518] Alias analysis chaining doesn't work
Message-ID: <200706181824.l5IIOfb5027145@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-18 13:24 -------
It works...

(gdb) r -qemu-aa -disable-output /tmp/a.bc -debug-pass=Structure -aa-eval
Starting program: /Volumes/src/llvm/Debug/bin/opt -qemu-aa -disable-output /tmp/a.bc -debug-
pass=Structure -aa-eval
Pass Arguments:  -qemu-aa -aa-eval -domtree -verify
Target Data Layout
Basic Alias Analysis (default AA impl)
  ModulePass Manager
    QEMU Alias Analysis
    FunctionPass Manager
      Exhaustive Alias Analysis Precision Evaluator
--      Exhaustive Alias Analysis Precision Evaluator
      Dominator Tree Construction
      Module Verifier
--      Module Verifier
--      Dominator Tree Construction
--    QEMU Alias Analysis
===== Alias Analysis Evaluator Report =====
  6 Total Alias Queries Performed
  3 no alias responses (50.0%)
  2 may alias responses (33.3%)
  1 must alias responses (16.6%)
  Alias Analysis Evaluator Pointer Alias Summary: 50%/33%/16%
  Alias Analysis Mod/Ref Evaluator Summary: no mod/ref!






------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 18 13:33:10 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jun 2007 13:33:10 -0500
Subject: [LLVMbugs] [Bug 1518] Alias analysis chaining doesn't work
Message-ID: <200706181833.l5IIXAiY027402@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-18 13:33 -------
:)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 18 14:15:23 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jun 2007 14:15:23 -0500
Subject: [LLVMbugs] [Bug 1519] NEW: LLVM type size doesn't match GCC type
	size
Message-ID: <200706181915.l5IJFNre028447@zion.cs.uiuc.edu>

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

           Summary: LLVM type size doesn't match GCC type size
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com


The assertion following assertion fail when compiling the attached source code
on linux-x86_64

cc1: ../../gcc/gcc/llvm-types.cpp:78: const llvm::Type*
llvm_set_type(tree_node*, const llvm::Type*): Assertion `!(__extension__ ({
const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code)
(__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type),
"../../gcc/gcc/llvm-types.cpp", 78, __FUNCTION__); __t; })->type.size) ||
!Ty->isSized() || !isInt64((__extension__ ({ const tree __t = (Tr); if
(tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type))
tree_class_check_failed (__t, (tcc_type), "../../gcc/gcc/llvm-types.cpp", 78,
__FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ ({ const
tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code)
(__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type),
"../../gcc/gcc/llvm-types.cpp", 78, __FUNCTION__); __t; })->type.size), true) ==
getTargetData().getTypeSizeInBits(Ty) && "LLVM type size doesn't match GCC type
size!"' failed



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 18 19:17:08 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jun 2007 19:17:08 -0500
Subject: [LLVMbugs] [Bug 1513] Wrong assignment of attributes
Message-ID: <200706190017.l5J0H8F8003003@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |miscompilation
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1



------- Additional Comments From sabre at nondot.org  2007-06-18 19:17 -------
Fixed.  Testcase here: CFrontend/2007-06-18-SextAttrAggregate.c

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070618/050591.html

Thanks Rafael!

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun 19 00:48:35 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jun 2007 00:48:35 -0500
Subject: [LLVMbugs] [Bug 1514] some llc options don't have descriptions in
	"-help" output
Message-ID: <200706190548.l5J5mZfn009721@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |quality-of-implementation
         Resolution|                            |FIXED
            Summary|llc options don't have      |some llc options don't have
                   |descriptions in "-help"     |descriptions in "-help"
                   |output                      |output
   Target Milestone|---                         |2.1



------- Additional Comments From sabre at nondot.org  2007-06-19 00:48 -------
Fixed, patches here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070618/050611.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070618/050612.html

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun 19 11:47:58 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jun 2007 11:47:58 -0500
Subject: [LLVMbugs] [Bug 1448] Pointer to invalid memory kept
Message-ID: <200706191647.l5JGlwBv001295@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |compile-fail
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1



------- Additional Comments From sabre at nondot.org  2007-06-19 11:47 -------
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070618/050627.html

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun 19 22:47:21 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jun 2007 22:47:21 -0500
Subject: [LLVMbugs] [Bug 1520] NEW: Miscompilation (?) of Ruby 1.8.6
Message-ID: <200706200347.l5K3lLgc018610@zion.cs.uiuc.edu>

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

           Summary: Miscompilation (?) of Ruby 1.8.6
           Product: tools
           Version: 2.0
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: OneSadCookie at gmail.com


llvm-gcc 2.0 appears to miscompile Ruby 1.8.6, though I don't understand the source one bit, so 
maybe it's just relying on something undefined in the language that it shouldn't...

CC=llvm-gcc ./configure; make; ./ruby -e 'begin; raise "hi"; rescue; retry; end'

exits with

-e:1: retry outside of rescue clause

the second time around, where it should loop indefinitely.  Compiled with the regular Apple GCC 4.0.1, 
it works fine.

This on an Intel Mac under 10.4.9 with the Xcode tools 2.4.1.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 20 13:52:34 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jun 2007 13:52:34 -0500
Subject: [LLVMbugs] [Bug 1518] Alias analysis chaining doesn't work
Message-ID: <200706201852.l5KIqY09018966@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-20 13:52 -------
Updated docs.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 20 14:59:41 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jun 2007 14:59:41 -0500
Subject: [LLVMbugs] [Bug 1521] NEW: isPassedByInvisibleReference misses a
	case
Message-ID: <200706201959.l5KJxfVF020328@zion.cs.uiuc.edu>

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

           Summary: isPassedByInvisibleReference misses a case
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com


The structure

struct cpp_num
{
  unsigned long high;
  unsigned long low;
  char unsignedp;
};

Should be passed in the stack, but isPassedByInvisibleReference doesn't notice
it on linux x86_64



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 20 17:22:32 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jun 2007 17:22:32 -0500
Subject: [LLVMbugs] [Bug 1511] Overloading functions by vector type produces
	silent failure or ICE
Message-ID: <200706202222.l5KMMWhX023326@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2007-06-20 17:22 -------
This is a bug in mainline GCC: http://gcc.gnu.org/PR12909

If someone is interested in fixing this, the fix should be done there, and then backported to llvm-gcc.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 20 18:40:09 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jun 2007 18:40:09 -0500
Subject: [LLVMbugs] [Bug 1522] NEW: 471.omnetpp dies at LLC compile on X86
Message-ID: <200706202340.l5KNe9qQ024710@zion.cs.uiuc.edu>

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

           Summary: 471.omnetpp dies at LLC compile on X86
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: resistor at mac.com


It looks like it has been for a long time.  This should probably get fixed at some point.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 20 19:48:18 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jun 2007 19:48:18 -0500
Subject: [LLVMbugs] [Bug 1295] Benchmarks/MiBench/consumer-typeset is set up
	wrong
Message-ID: <200706210048.l5L0mIFg026418@zion.cs.uiuc.edu>

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

evan.cheng at apple.com changed:

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



------- Additional Comments From evan.cheng at apple.com  2007-06-20 19:48 -------
Yes, it's a two pass run. Added '-x' to RUN_OPTIONS.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 20 22:34:08 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jun 2007 22:34:08 -0500
Subject: [LLVMbugs] [Bug 1523] NEW: trivial functions not inlined at -O2
Message-ID: <200706210334.l5L3Y84X029112@zion.cs.uiuc.edu>

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

           Summary: trivial functions not inlined at -O2
           Product: tools
           Version: 2.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


This code isn't getting inlined at -O2:

int add (int x, int y);
int add (int x, int y) {
    return x + y;
}
int embeddedFunction (int x, int y);
int embeddedFunction (int x, int y) {
    return add(x,y);
}
int recursiveFunction (int x, int y);
int recursiveFunction (int x, int y) {
    return add(add(x,y),y);
}


I don't follow the code in llvm-backend.cpp:

    if (optimize > 1) {
      if (flag_inline_trees > 1)                // respect -fno-inline-functions
        PM->add(createFunctionInliningPass());  // Inline small functions
      if (flag_unit_at_a_time && !lang_hooks.flag_no_builtin())
        PM->add(createSimplifyLibCallsPass());  // Library Call Optimizations

      if (optimize > 2)
        PM->add(createArgumentPromotionPass()); // Scalarize uninlined fn args
    }

Maybe flag_inline_trees should be >= 1 ?

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 20 23:07:52 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jun 2007 23:07:52 -0500
Subject: [LLVMbugs] [Bug 1524] NEW: Improvements for mac release binaries
Message-ID: <200706210407.l5L47q12029732@zion.cs.uiuc.edu>

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

           Summary: Improvements for mac release binaries
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


For LLVM 2.1, we should change the official mac os/x binaries to be an installable disk image (dmg file) 
instead of the current powerpc and intel tarball.

Ideally, it would be a simple dmg file that installs the llvm binaries in /usr/local/bin.  These binaries 
should be the "universal" GCC roots built "apple style", so they support the -arch options etc.

The hard part is figuring out how to do this, we even already have a script to do it.  We just need to update 
docs/HowToReleaseLLVM.html with the instructions for the next release.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Jun 21 03:34:05 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jun 2007 03:34:05 -0500
Subject: [LLVMbugs] [Bug 1525] NEW: llvm CVS: llvm2cpp generates incorrect
	code when string are used
Message-ID: <200706210834.l5L8Y5bU011285@zion.cs.uiuc.edu>

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

           Summary: llvm CVS: llvm2cpp generates incorrect code when string
                    are used
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: letz at grame.fr


llvm2cpp generates incorrect code, that does not run correctly when compiled and run, when string are 
used:

Starting from the following code:

#include <stdio.h>

int main()
{
	printf("foo");
	return 0;
}

the generated code is: 

// Generated by llvm2cpp - DO NOT MODIFY!

#include <llvm/Module.h>
#include <llvm/DerivedTypes.h>
#include <llvm/Constants.h>
#include <llvm/GlobalVariable.h>
#include <llvm/Function.h>
#include <llvm/CallingConv.h>
#include <llvm/BasicBlock.h>
#include <llvm/Instructions.h>
#include <llvm/InlineAsm.h>
#include <llvm/ParameterAttributes.h>
#include <llvm/Support/MathExtras.h>
#include <llvm/Pass.h>
#include <llvm/PassManager.h>
#include <llvm/Analysis/Verifier.h>
#include <llvm/Assembly/PrintModulePass.h>
#include <algorithm>
#include <iostream>

using namespace llvm;

Module* makeLLVMModule();

int main(int argc, char**argv) {
  Module* Mod = makeLLVMModule();
  verifyModule(*Mod, PrintMessageAction);
  std::cerr.flush();
  std::cout.flush();
  PassManager PM;
  PM.add(new PrintModulePass(&llvm::cout));
  PM.run(*Mod);
  return 0;
}


Module* makeLLVMModule() {
  // Module Construction
  Module* mod = new Module("function.bc");
  mod->setDataLayout("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");
  mod->setTargetTriple("i686-apple-darwin8.9.1");
  
  // Type Definitions
  ArrayType* ArrayTy_0 = ArrayType::get(IntegerType::get(8), 4);
  
  PointerType* PointerTy_1 = PointerType::get(ArrayTy_0);
  
  std::vector<const Type*>FuncTy_2_args;
  ParamAttrsList *FuncTy_2_PAL = 0;
  FunctionType* FuncTy_2 = FunctionType::get(
    /*Result=*/IntegerType::get(32),
    /*Params=*/FuncTy_2_args,
    /*isVarArg=*/false,
    /*ParamAttrs=*/FuncTy_2_PAL);
  
  std::vector<const Type*>FuncTy_4_args;
  PointerType* PointerTy_5 = PointerType::get(IntegerType::get(8));
  
  FuncTy_4_args.push_back(PointerTy_5);
  ParamAttrsList *FuncTy_4_PAL = 0;
  FunctionType* FuncTy_4 = FunctionType::get(
    /*Result=*/IntegerType::get(32),
    /*Params=*/FuncTy_4_args,
    /*isVarArg=*/true,
    /*ParamAttrs=*/FuncTy_4_PAL);
  
  PointerType* PointerTy_3 = PointerType::get(FuncTy_4);
  
  
  // Function Declarations
  
  Function* func_main = new Function(
    /*Type=*/FuncTy_2,
    /*Linkage=*/GlobalValue::ExternalLinkage,
    /*Name=*/"main", mod); 
  func_main->setCallingConv(CallingConv::C);
  
  Function* func_printf = new Function(
    /*Type=*/FuncTy_4,
    /*Linkage=*/GlobalValue::ExternalLinkage,
    /*Name=*/"printf", mod); // (external, no body)
  func_printf->setCallingConv(CallingConv::C);
  
  // Global Variable Declarations

  
  GlobalVariable* gvar_array__str = new GlobalVariable(
  /*Type=*/ArrayTy_0,
  /*isConstant=*/true,
  /*Linkage=*/GlobalValue::InternalLinkage,
  /*Initializer=*/0, // has initializer, specified below
  /*Name=*/".str",
  mod);
  
  // Constant Definitions
  Constant* const_array_6 = ConstantArray::get("foo\x00", false);
  std::vector<Constant*> const_ptr_7_indices;
  Constant* const_int32_8 = Constant::getNullValue(IntegerType::get(32));
  const_ptr_7_indices.push_back(const_int32_8);
  const_ptr_7_indices.push_back(const_int32_8);
  Constant* const_ptr_7 = ConstantExpr::getGetElementPtr(gvar_array__str, &const_ptr_7_indices[0], 2 );
  
  // Global Variable Definitions
  gvar_array__str->setInitializer(const_array_6);
  
  // Function Definitions
  
  // Function: main (func_main)
  {
    
    BasicBlock* label_entry = new BasicBlock("entry",func_main,0);
    
    // Block entry (label_entry)
    CallInst* int32_tmp2 = new CallInst(func_printf, const_ptr_7, "tmp2", label_entry);
    int32_tmp2->setCallingConv(CallingConv::C);
    int32_tmp2->setTailCall(true);
    new ReturnInst(const_int32_8, label_entry);
    
  }
  
  return mod;
}

then when compiled and run give the error:

Global variable initializer type does not match global variable type!
[4 x i8]* @.str
Broken module found, verification continues.
; ModuleID = 'function.bc'
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"
target triple = "i686-apple-darwin8.9.1"
@.str = internal constant [4 x i8] c"foo"               ; <[4 x i8]*> [#uses=1]

define i32 @main() {
entry:
        %tmp2 = tail call i32 (i8*, ...)* @printf( i8* getelementptr ([4 x i8]* @.str, i32 0, i32 0) )          ; 
<i32> [#uses=0]
        ret i32 0
}

declare i32 @printf(i8*, ...)

If I *manually* edit the gnerated code to be : Constant* const_array_6 = ConstantArray::get("foo ", 
false); then it works.

So the issue seems a string termination problem.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Jun 21 18:37:59 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jun 2007 18:37:59 -0500
Subject: [LLVMbugs] [Bug 1519] LLVM type size doesn't match GCC type size
Message-ID: <200706212337.l5LNbxv1029768@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-21 18:37 -------
Applied your patch.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070618/date.html#50685




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 23 10:55:14 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jun 2007 10:55:14 -0500
Subject: [LLVMbugs] [Bug 1526] NEW: Bad TargetData ctor used
Message-ID: <200706231555.l5NFtE9f005670@zion.cs.uiuc.edu>

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

           Summary: Bad TargetData ctor used
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


This might be a PassManager bug:

$ opt -analyze -inline b.bc
opt: /home/nicholas/llvm/include/llvm/Target/TargetData.h:113:
llvm::TargetData::TargetData(): Assertion `0 && "ERROR: Bad TargetData ctor
used.  " "Tool did not specify a TargetData to use?"' failed.
llvm/Debug/bin/opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8648c6a]
llvm/Debug/bin/opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8648f30]
[0xffffe500]
Aborted



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 23 11:52:31 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jun 2007 11:52:31 -0500
Subject: [LLVMbugs] [Bug 1527] NEW: bugpoint should check for changes when
	reducing miscompile
Message-ID: <200706231652.l5NGqVJv007089@zion.cs.uiuc.edu>

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

           Summary: bugpoint should check for changes when reducing
                    miscompile
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: bugpoint
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


As a performance hack, bugpoint should try once to see if it can reduce the set
of functions, basic blocks or instructions by comparing the code before and
after the passes.

Chances are, if a Function didn't change at all when run through the passes then
it's not related to the problem being reduced. This should happen once when
bugpoint starts looking into functions before it starts the binary search. (It
then tests whether the problem can be reproduced with the remaining functions
and if not, starts the binary cut from the whole set.)

Then once it's done the binary search on functions, it can do the same on basic
blocks before it starts doing the binary search on them. Finally, the same
applies for instructions.

You might also consider whether we can do that for the optimization passes by
comparing the code between each pass and eliminating those where the code
doesn't change, however this is less likely to work when the reduction is a
problem updating analyses.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 23 12:15:07 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jun 2007 12:15:07 -0500
Subject: [LLVMbugs] [Bug 1528] NEW: instcombine miscompiles lshr i32 %x, 31
Message-ID: <200706231715.l5NHF7Y2008000@zion.cs.uiuc.edu>

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

           Summary: instcombine miscompiles lshr i32 %x, 31
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


This is a reduction from SPASS. lshr(ptrtoint, bitwidth-1) seems to get
miscompiled by instcombine:

$ cat pr1528.ll

define i1 @foo(i32 %tmp1213) {
  %S.lobit.i.i = lshr i32 %tmp1213, 31
  %tmp3.i684 = icmp eq i32 %S.lobit.i.i, 0
  ret i1 %tmp3.i684
}

$ llvm-as < pr1528.ll | opt -instcombine | llvm-dis
; ModuleID = '<stdin>'

define i1 @foo(i32 %tmp1213) {
        %tmp3.i684 = icmp sgt i32 %tmp1213, -1          ; <i1> [#uses=1]
        ret i1 %tmp3.i684
}

If %tmp1213 is 4 then the original returns false while the post-instcombine code
returns true.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 23 23:25:54 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jun 2007 23:25:54 -0500
Subject: [LLVMbugs] [Bug 1528] instcombine miscompiles lshr i32 %x, 31
Message-ID: <200706240425.l5O4PssH020069@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

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



------- Additional Comments From nicholas at mxc.ca  2007-06-23 23:25 -------
Never mind.

Given 0, they both return true. Given -1, they both return false.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Sat Jun 23 23:44:13 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jun 2007 23:44:13 -0500
Subject: [LLVMbugs] [Bug 1507] Break predicate simplifier free from ETForest
Message-ID: <200706240444.l5O4iDng020421@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

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



------- Additional Comments From nicholas at mxc.ca  2007-06-23 23:44 -------
Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070618/050711.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Mon Jun 25 11:46:48 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Jun 2007 11:46:48 -0500
Subject: [LLVMbugs] [Bug 1525] llvm CVS: llvm2cpp generates incorrect code
	when string are used
Message-ID: <200706251646.l5PGkmnw000363@zion.cs.uiuc.edu>

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

rspencer at reidspencer.com changed:

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



------- Additional Comments From rspencer at reidspencer.com  2007-06-25 11:46 -------
Fixed with this patch:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070625/050728.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Tue Jun 26 11:53:01 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jun 2007 11:53:01 -0500
Subject: [LLVMbugs] [Bug 1529] NEW: Recent vector codegen regression
Message-ID: <200706261653.l5QGr19G006337@zion.cs.uiuc.edu>

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

           Summary: Recent vector codegen regression
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


I assume this is due to Dan's recent patches:

$ llvm-as < test.ll | llc -march=ppc32 -mcpu=g5
..
/Volumes/ProjectsDisk/cvs/llvm/include/llvm/Target/TargetLowering.h:123: failed assertion `!
MVT::isExtendedValueType(VT)'


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"
target triple = "powerpc-apple-darwin8.8.0"

define i32 @main() {
entry:
        br label %bb

bb:             ; preds = %bb, %entry
        br i1 false, label %bb15, label %bb

bb15:           ; preds = %bb15, %bb
        %tmp21 = add <8 x double> zeroinitializer, zeroinitializer              ; <<8 x double>> [#uses=1]
        br i1 false, label %bb15, label %bb30

bb30:           ; preds = %bb15
        store <8 x double> %tmp21, <8 x double>* null
        ret i32 0
}



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 27 12:10:20 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jun 2007 12:10:20 -0500
Subject: [LLVMbugs] [Bug 1529] Recent vector codegen regression
Message-ID: <200706271710.l5RHAKd5004878@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |2.1



------- Additional Comments From sabre at nondot.org  2007-06-27 12:10 -------
Dan's patch fixed this, thanks!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070625/050788.html



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 27 13:52:04 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jun 2007 13:52:04 -0500
Subject: [LLVMbugs] [Bug 1502] live-interval trouble with exception handling
Message-ID: <200706271852.l5RIq4XF007279@zion.cs.uiuc.edu>

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

evan.cheng at apple.com changed:

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



------- Additional Comments From evan.cheng at apple.com  2007-06-27 13:52 -------
Nevermind. I've decided the proper fix is to simply add the EH register(s) as a
livein in the landing pad successor (and any block in the path from the landing
pad to the said block). I've also fixed live-interval to not to puke if a livein
is not used.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070625/050807.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070625/050808.html

Let me know if you run into other issues.

2007-04-14-EHSelectorCrash.ll is still XFAIL due to the CatchInfo issue. Please
open another bug to track that (if there isn't one already).




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 27 17:19:10 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jun 2007 17:19:10 -0500
Subject: [LLVMbugs] [Bug 1530] NEW: missing implied subtarget features
Message-ID: <200706272219.l5RMJAbi032242@zion.cs.uiuc.edu>

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

           Summary: missing implied subtarget features
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Target Description Classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: djg at cray.com


llc -march=x86-64 -mcpu=opteron

gives this message:

Warning: 64-bit processors all have at least SSE2.

Looking at the code in lib/Target/SubtargetFeature.cpp,
SetImpliedBits isn't called for the base CPU's feature
bits, so even though "opteron" has the 64-bit feature
and 64-bit implies SSE2, -mcpu=opteron doesn't
automatically enable SSE2.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Wed Jun 27 18:35:23 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jun 2007 18:35:23 -0500
Subject: [LLVMbugs] [Bug 1530] missing implied subtarget features
Message-ID: <200706272335.l5RNZNHQ021204@zion.cs.uiuc.edu>

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

isanbard at gmail.com changed:

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



------- Additional Comments From isanbard at gmail.com  2007-06-27 18:35 -------
We weren't setting implied features when looking at the CPU's features.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070625/050818.html

-bw



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From bugzilla-daemon at cs.uiuc.edu  Thu Jun 28 18:11:28 2007
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Jun 2007 18:11:28 -0500
Subject: [LLVMbugs] [Bug 1526] Bad TargetData ctor used
Message-ID: <200706282311.l5SNBSii006377@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2007-06-28 18:11 -------
Fixed.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070625/050846.html




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.