From bugzilla-daemon at cs.uiuc.edu  Sat Sep  2 09:36:04 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 2 Sep 2006 09:36:04 -0500
Subject: [LLVMbugs] [Bug 895] NEW: asmparser doesn't handle undeclared
	function very well
Message-ID: <200609021436.k82Ea41d032572@zion.cs.uiuc.edu>

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

           Summary: asmparser doesn't handle undeclared function very well
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: LLVM assembly language parser
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


This llvm asm file:

  void %foo() { 
    call void %bar();
    ret void;
  }

is missing the definition of function bar. Running llvm-as produces this mess:
$ llvm-as < foo.l
Leaked LLVM objects found: after running pass 'Immediate Dominators Construction':
        void ()* <badref>


This is probably because you removed an object, but didn't delete it.  Please
check your code for memory leaks.
llvm-as: assembly parsed, but does not verify as correct!
Referring to an argument in another function!
        call void <badref>( )
Broken module found, compilation terminated.
Broken module found, compilation terminated.

Which is helpful enough to point to the problem, but not as much as:
llvm-as: <stdin>:2,0: Reference to an undefined function: 'bar'

for example.



------- 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 Sep  2 12:25:45 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 2 Sep 2006 12:25:45 -0500
Subject: [LLVMbugs] [Bug 891] "make bugpoint-gccas" spews binary garbage in
	Burg
Message-ID: <200609021725.k82HPjI9002658@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Platform|PC                          |All
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-09-02 12:25 -------
Oops, didn't notice this bug.  Yes you're right, that really is impolite! :)

Fix here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060828/037386.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 Sep  5 12:44:37 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Sep 2006 12:44:37 -0500
Subject: [LLVMbugs] [Bug 896] NEW: libgcc_s.so not compatible with
	libstdc++.so.6.0.8?
Message-ID: <200609051744.k85HibCj018695@zion.cs.uiuc.edu>

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

           Summary: libgcc_s.so not compatible with libstdc++.so.6.0.8?
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


I'm trying to use gcc4.1.2 (20060901 prerelease) to build llvm-gcc.
Unfortunately, I get a missing symbol error in the build process:

/home/nicholas/llvm-gcc/build/gcc/xgcc:
/home/nicholas/llvm-gcc/build/gcc/libgcc_s.so.1: version `GCC_4.2.0' not found
(required by /usr/lib/libstdc++.so.6)
make[1]: *** [specs] Error 1
make[1]: Leaving directory `/home/nicholas/llvm-gcc/build/gcc'
make: *** [all-gcc] Error 2

I'm not sure what else to say about this. I also have a /usr/lib/libstdc++.so.5
which I assume is for older compilers. My /usr/lib/libstdc++.so is a symlink to
libstdc++.so.6.0.8.



------- 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 Sep  5 13:30:50 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Sep 2006 13:30:50 -0500
Subject: [LLVMbugs] [Bug 896] libgcc_s.so not compatible with
	libstdc++.so.6.0.8?
Message-ID: <200609051830.k85IUoru019527@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

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



------- Additional Comments From nicholas at mxc.ca  2006-09-05 13:30 -------
Er, this seems to already be discussed:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-June/006164.html

Dropping bug. I'll reopen it if it just won't go away.




------- 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 Sep  5 19:13:08 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Sep 2006 19:13:08 -0500
Subject: [LLVMbugs] [Bug 897] NEW: ADT/SmallVector.h violates aliasing rules
Message-ID: <200609060013.k860D8c6024843@zion.cs.uiuc.edu>

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

           Summary: ADT/SmallVector.h violates aliasing rules
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


gcc 4.1.2 emits the following warning on SmallVector:

llvm/include/llvm/ADT/SmallVector.h:46: warning: dereferencing type-punned
pointer will break strict-aliasing rules

This appears to be due to the use of a union:

template <typename T>
class SmallVectorImpl {
  T *Begin, *End, *Capacity;
  
  // Allocate raw space for N elements of type T.  If T has a ctor or dtor, we
  // don't want it to be automatically run, so we need to represent the space as
  // something else.  An array of char would work great, but might not be
  // aligned sufficiently.  Instead, we either use GCC extensions, or some
  // number of union instances for the space, which guarantee maximal alignment.
protected:
  union U {
    double D;
    long double LD;
    long long L;
    void *P;
  } FirstEl;
  // Space after 'FirstEl' is clobbered, do not add any instance vars after it.
public:
  // Default ctor - Initialize to empty.
  SmallVectorImpl(unsigned N)
    : Begin((T*)&FirstEl), End((T*)&FirstEl), Capacity((T*)&FirstEl+N) {
  }

Line 46 being the one with where Begin, End and Capacity are being assigned. The
trouble is that you aren't allowed to put a "T" in the union anyways (otherwise,
that would be a neat hack to preserve the type without going through the
constructor).



------- 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 Sep  5 21:13:08 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Sep 2006 21:13:08 -0500
Subject: [LLVMbugs] [Bug 898] NEW: llvm-gcc4 doesn't compile after
	TargetMachine.h changes
Message-ID: <200609060213.k862D83g026650@zion.cs.uiuc.edu>

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

           Summary: llvm-gcc4 doesn't compile after TargetMachine.h changes
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


The first argument to addPassesToEmitFile now requires a FunctionPassManager but
llvm-backend.cpp is providing a PassManager. The compiler rightfully complains.

Output from "make":
c++ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -DHAVE_CONFIG_H -Wno-unused
-DTARGET_NAME=\"i686-pc-linux-gnu\" -DNDEBUG -DENABLE_LLVM -D__STDC_LIMIT_MACROS
  -I. -I. -I../../svnsrc/gcc -I../../svnsrc/gcc/. -I../../svnsrc/gcc/../include
-I../../svnsrc/gcc/../libcpp/include  -I/proj/llvm/llvm/include
-I/proj/llvm/build/include ../../svnsrc/gcc/llvm-backend.cpp -o llvm-backend.o
../../svnsrc/gcc/llvm-backend.cpp: In function `void llvm_asm_file_start()':
../../svnsrc/gcc/llvm-backend.cpp:295: error: no matching function for call to
`llvm::TargetMachine::addPassesToEmitFile(llvm::PassManager&,
std::basic_ostream<char, std::char_traits<char> >&,
llvm::TargetMachine::CodeGenFileType, bool)'
/proj/llvm/llvm/include/llvm/Target/TargetMachine.h:155: note: candidates are:
virtual bool
llvm::TargetMachine::addPassesToEmitFile(llvm::FunctionPassManager&,
std::ostream&, llvm::TargetMachine::CodeGenFileType, bool)
make[1]: *** [llvm-backend.o] Error 1
make[1]: Leaving directory `/proj/llvm/cfe/build/gcc'
make: *** [all-gcc] Error 2



------- 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 Sep  6 09:11:13 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Sep 2006 09:11:13 -0500
Subject: [LLVMbugs] [Bug 896] libgcc_s.so not compatible with
	libstdc++.so.6.0.8?
Message-ID: <200609061411.k86EBDD4027634@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

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



------- Additional Comments From nicholas at mxc.ca  2006-09-06 09:11 -------
Modifying the Makefile doesn't fix this bug for me. I've removed my build
directory and started from scratch and I still can't get llvm-gcc built.




------- 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 Sep  6 16:14:20 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Sep 2006 16:14:20 -0500
Subject: [LLVMbugs] [Bug 898] llvm-gcc4 doesn't compile after
	TargetMachine.h changes
Message-ID: <200609062114.k86LEKVo002364@zion.cs.uiuc.edu>

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

rspencer at x10sys.com changed:

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



------- Additional Comments From rspencer at x10sys.com  2006-09-06 16:14 -------
It compiles fine after the svn update.



------- 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 Sep  6 16:47:05 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Sep 2006 16:47:05 -0500
Subject: [LLVMbugs] [Bug 899] NEW: Add gcc4 vs. gcc3 differences note
Message-ID: <200609062147.k86Ll5FA002932@zion.cs.uiuc.edu>

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

           Summary: Add gcc4 vs. gcc3 differences note
           Product: Website
           Version: unspecified
          Platform: Other
               URL: http://llvm.org/docs/GettingStarted.html
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Documentation
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: scottm at aero.org


The difference between the gcc3 and gcc4 frontends is a FAQ in the mailing 
lists. This patch addresses this question, namely, the confusion between the 
output from the gcc4 frontend (by default, native, "--emit-llvm" needed in 
CFLAGS to emit bytecode) and the gcc3 frontend (by default, bytecode). Hell, 
this comment is longer than the actual disclaimer.

Also, ran the HTML through HTMLtidy, fixed duplicated/missing anchor tags and 
other various complaints.



------- 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 Sep  6 23:19:50 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Sep 2006 23:19:50 -0500
Subject: [LLVMbugs] [Bug 896] libgcc_s.so not compatible with
	libstdc++.so.6.0.8?
Message-ID: <200609070419.k874JoeQ009960@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

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



------- Additional Comments From nicholas at mxc.ca  2006-09-06 23:19 -------
I'm seeing the same issue compiling WINE, which suggests that it isn't confined
to LLVM. My vendor has a bug open for this issue: http://bugs.debian.org/386121



------- 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 Sep  6 23:20:37 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Sep 2006 23:20:37 -0500
Subject: [LLVMbugs] [Bug 899] Add gcc4 vs. gcc3 differences note
Message-ID: <200609070420.k874Kbhj009997@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2006-09-06 23:20 -------
Look great, thanks for the patch, applied:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060904/037556.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  Thu Sep  7 13:38:17 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 7 Sep 2006 13:38:17 -0500
Subject: [LLVMbugs] [Bug 900] NEW: llvm-testresults email needs significant
	improvement
Message-ID: <200609071838.k87IcHQr008563@zion.cs.uiuc.edu>

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

           Summary: llvm-testresults email needs significant improvement
           Product: Test Suite
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Nightly Tester
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


Zero'th:  Showstopper.
 1. The test does not correctly list newly passing and newly failing llvm-test and dejagnu results 
correctly.  This is a critical broken aspect.  For example, see here:
http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2006-September/004047.html
  Note: "Benchmarks/Stanford/Treesort (JIT*) changed %100.00 (0.91 => )"

First: Major functionality problems.

1. "Significant changes in test results:" doesn't list file size changes.
2. In http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2006-September/004035.html , what is the ":" 
catagory (with tag ())??
3. In the same, what is JIT*?
4. http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2006-September/004037.html what is GCCAS*, 
Bytecode*?


Second, minor weirdness:

1. See http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2006-September/004032.html
  There is no "None" after "New Test Passes", why?
  There should be no blank lines between the None lines to make it more compact.

2. Formatting issues:
    http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2006-September/004030.html
  The first line in a section has the tag (e.g. "(LLC)") removed and the % in the right place.  Later entries 
in each section have the redundant tag and have the % in the wrong place.

3. http://lists.cs.uiuc.edu/pipermail/llvm-testresults/2006-September/004040.html : "Significant 
changes in test results:" should print 'none' when appropriate.


Since no-one "owns" the nightly tester anymore, I thought I would file this to see if anyone is interested 
in tackling these issues.

-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 Sep  7 14:01:11 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 7 Sep 2006 14:01:11 -0500
Subject: [LLVMbugs] [Bug 901] NEW: Web interfacce should provide access to
	test logs
Message-ID: <200609071901.k87J1BcH009020@zion.cs.uiuc.edu>

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

           Summary: Web interfacce should provide access to test logs
           Product: Test Suite
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Nightly Tester
        AssignedTo: jlaskey at apple.com
        ReportedBy: evan.cheng at apple.com


Right now only the build log is accessible via llvm.org/nightlytest. It would be
nice if all the other test logs are made available as well.



------- 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 Sep  8 01:41:54 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Sep 2006 01:41:54 -0500
Subject: [LLVMbugs] [Bug 902] NEW: asmparser crash on invalid
Message-ID: <200609080641.k886fsxH020722@zion.cs.uiuc.edu>

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

           Summary: asmparser crash on invalid
           Product: libraries
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM assembly language parser
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


This input crashes the asmparser. This is a regression from the EH removal patches.

void %test() {
        add int 1, 2.0
        ret void
}

Perhaps we need a sj/lj solution for the asmparser?

-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 Sep  8 12:22:51 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Sep 2006 12:22:51 -0500
Subject: [LLVMbugs] [Bug 792] Factor AsmWriter out of lib/VMCore
Message-ID: <200609081722.k88HMpbZ018383@zion.cs.uiuc.edu>

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

rspencer at x10sys.com changed:

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



------- Additional Comments From rspencer at x10sys.com  2006-09-08 12:22 -------
This has turned out to be more effort than its worth. The main issue is trying
to make completely independent libraries (no cycles).  AsmWriter has to rely on
VMCore and VMCore has numerous places where it must call AsmWriter. Those places
can't be easily extracted.

Consequently, I'm resolving this as "LATER".  It would still be a nice-to-have,
but its not worth spending a couple of weeks on.



------- 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 Sep  8 12:41:51 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Sep 2006 12:41:51 -0500
Subject: [LLVMbugs] [Bug 903] NEW: Better way to handle asm writing from the
	tools.
Message-ID: <200609081741.k88Hfpuj018734@zion.cs.uiuc.edu>

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

           Summary: Better  way to handle asm writing from the tools.
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jlaskey at apple.com


I thought if I batted around some ideas we could work out some long term solutions to maintaining 
asm writing.

So let's say we have these .tai (target asm info) files around, and we stick asm properties in them. (Why 
not .td files?  Well I'll get to that.)

Thus we might have something like;

namespace Darwin;

properties {
  Comment               = ";";
  Global                = "_";
  Local                 = "L";
  ZeroDirective         = ".space";
  SetDirective          = ".set";
  Data64bitsDirective   = isPPC64 ? ".quad" : 0; 
  AlignmentIsInBytes    = false;
  ConstantPoolSection   = ".const";
  JumpTableDataSection  = ".const";
  JumpTableTextSection  = ".text";
  LCOMMDirective        = ".lcomm";
  StaticCtorsSection    = ".mod_init_func";
  StaticDtorsSection    = ".mod_term_func";
  InlineAsmStart        = "# InlineAsm Start";
  InlineAsmEnd          = "# InlineAsm End";
 
  NeedsSet              = true;
  AddressSize           = isPPC64 ? 8 : 4;
  DwarfAbbrevSection    = ".section __DWARF,__debug_abbrev";
  DwarfInfoSection      = ".section __DWARF,__debug_info";
  DwarfLineSection      = ".section __DWARF,__debug_line";
  DwarfFrameSection     = ".section __DWARF,__debug_frame";
  DwarfPubNamesSection  = ".section __DWARF,__debug_pubnames";
  DwarfPubTypesSection  = ".section __DWARF,__debug_pubtypes";
  DwarfStrSection       = ".section __DWARF,__debug_str";
  DwarfLocSection       = ".section __DWARF,__debug_loc";
  DwarfARangesSection   = ".section __DWARF,__debug_aranges";
  DwarfRangesSection    = ".section __DWARF,__debug_ranges";
  DwarfMacInfoSection   = ".section __DWARF,__debug_macinfo";
}

Straight forward.  But what I really want is code smidgens. Example, in the Darwin asm printer we have;

      SwitchToTextSection(".section __TEXT,__symbol_stub1,symbol_stubs,"
                          "pure_instructions,16", 0);
      EmitAlignment(4);
      O << "L" << *i << "$stub:\n";
      O << "\t.indirect_symbol " << *i << "\n";
      O << "\tlis r11,ha16(L" << *i << "$lazy_ptr)\n";
      if (isPPC64)
        O << "\tldu r12,lo16(L" << *i << "$lazy_ptr)(r11)\n";
      else
        O << "\tlwzu r12,lo16(L" << *i << "$lazy_ptr)(r11)\n";
      O << "\tmtctr r12\n";
      O << "\tbctr\n";
      SwitchToDataSection(".lazy_symbol_pointer", 0);
      O << "L" << *i << "$lazy_ptr:\n";
      O << "\t.indirect_symbol " << *i << "\n";
      if (isPPC64)
        O << "\t.quad dyld_stub_binding_helper\n";
      else
        O << "\t.long dyld_stub_binding_helper\n";

What if I could do something like the following in the .tai file.

function printFunctionStub(Name) {
    .section                __TEXT,__symbol_stub1,symbol_stubs,pure_instructions,16
    .align                  4
L#{Name}$stub:
    .indirect_symbol        #{Name}     ; comment of some sort
    lis                     r11,ha16(#{Local}#{Name}$lazy_ptr)
    #{isPPC64?"ldu":"lwzu"} r12,lo16(#{Local}#{Name}$lazy_ptr)(r11)
    mtctr                   r12
    bctr
    .lazy_symbol_pointer
L#{Name}$lazy_ptr:
    .indirect_symbol        #{Name}     ; comment of some sort
    .ptr                    dyld_stub_binding_helper
}

Or more generically;

function printFunctionStub(Name) {
    .section                __TEXT,__symbol_stub1,symbol_stubs,pure_instructions,16
    .align                  4
#{Local}#{Name}$stub:
    .indirect_symbol        #{Name}     #{Comment} comment of some sort
    lis                     r11,ha16(#{Local}#{Name}$lazy_ptr)
    #{isPPC64?"ldu":"lwzu"} r12,lo16(#{Local}#{Name}$lazy_ptr)(r11)
    mtctr                   r12
    bctr
    .lazy_symbol_pointer
#{Local}#{Name}$lazy_ptr:
    .indirect_symbol        #{Name}     #{Comment} comment of some sort
    .ptr                    dyld_stub_binding_helper
}

General Notes:

- TAI functions generate equivalent C++ functions.
- The TAI tool recognizes generic features of asm code, like labels, ops, operands and comments,, and 
does the correct thing based on the current properties.
- All arguments and variables would always be assumed to be strings.  So numeric values and machine 
operand would be cast to strings.
- Tokens in the form of .xxxxx would be recognized as directives and may be acted upon.  
Example .section would only be emitted if not same as current section.  .text may become .section 
TEXT,__text or whatever.
- Patterns in the form of #{expression} get substituted with the result of the expression (ala scripting/
ruby.)
- Variables in expressions may be visible properties, target constructed or arguments.
- L$ and G$ are shorthand for #{Local} and #{Global}.  Simplifies defining labels.
- ";" is shorthand for #{Comment}.  Simplifies defining comments.  If the verbose flag is off then all 
comments are suppressed.
- Spaces between first column/directives, directives/operand and operand/comment are converted to 
tabs.

Example Notes:
- The above tai function gets translated into a C++ function called 
DarwinAsmPrinter::printFunctionStub (base on name and namespace)
- .align would be assumed to be in bytes but properties may imply a conversion to log2 bytes.
- .indirect_symbol is not recognized so is written as is.
-  #{isPPC64?"ldu":"lwzu"} gets evaluated at runtime and the result.
- .ptr is recognized as a special directive and emits .word or .quad (based on properties.)  .quad could 
get converted to two .long if not supported.

Dwarf example;

Instead of;

      EmitInt32(0x1c); EOL("Length of Address Ranges Info");
     
      EmitInt16(DWARF_VERSION); EOL("Dwarf Version");
     
      EmitReference("info_begin", Unit->getID());
      EOL("Offset of Compilation Unit Info");

      EmitInt8(TAI->getAddressSize()); EOL("Size of Address");

      EmitInt8(0); EOL("Size of Segment Descriptor");

      EmitInt16(0);  EOL("Pad (1)");
      EmitInt16(0);  EOL("Pad (2)");

      // Range 1
      EmitReference("text_begin", 0); EOL("Address");
      EmitDifference("text_end", 0, "text_begin", 0); EOL("Length");

      EmitInt32(0); EOL("EOM (1)");
      EmitInt32(0); EOL("EOM (2)");

We'd have;

namespace Dwarf;       
 
function printDwarfARanges(Version, InfoNum) {
    .word           0x1c                                ; Length of Address Ranges Info
    .short          #{Version}                          ; Dwarf Version
    .ptr            L$debug_info_begin#{InfoNum}        ; Offset of Compilation Unit Info
    .byte           #{AddressSize}                      ; Size of Address
    .byte           0                                   ; Size of Segment Descriptor
    .byte           0, 0                                ; Pad
    .ptr            L$debug_text_begin                  ; Address
    .ptr            L$debug_text_end-L$debug_text_begin ; Length
    .byte           0, 0                                ; EOM
}

Much easier to read and maintain, and allow for generic code patterns to be used across targets.

Now back to why not .td files.  No good reason - just add "here" strings to td and it might work out 
fine.

<<<EOS
    .word           0x1c                                ; Length of Address Ranges Info
    .short          #{Version}                          ; Dwarf Version
    .ptr            L$debug_info_begin#{InfoNum}        ; Offset of Compilation Unit Info
    .byte           #{AddressSize}                      ; Size of Address
    .byte           0                                   ; Size of Segment Descriptor
    .byte           0, 0                                ; Pad
    .ptr            L$debug_text_begin                  ; Address
    .ptr            L$debug_text_end-L$debug_text_begin ; Length
    .byte           0, 0                                ; EOM
EOS



------- 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 Sep 10 10:05:58 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 10 Sep 2006 10:05:58 -0500
Subject: [LLVMbugs] [Bug 904] NEW: #line directives are mishandled in debug
	info generation
Message-ID: <200609101505.k8AF5wcc016881@zion.cs.uiuc.edu>

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

           Summary: #line directives are mishandled in debug info generation
           Product: tools
           Version: 1.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Yossi.Kreinin at Mobileye.com


Apparently llvm-gcc ignores #line directives in source files when  generating
debug information. When I compile this:

//test
int f(int a)
{
#line 1 "someplace"
   return a*a;
}
//end

with `llvm -g -S lines.c`, `someplace' is not mentioned in lines.s.  It also
looks like functions #included from header files get  attributed to the
#including file (albeit at the right line number).

P.S. I don't see a way to attach files, so here's the pasted contents of:

1. llvm-gcc output:

; GNU C version 3.4-llvm 20051104 (LLVM 1.6) (i686-pc-linux-gnu)
;       compiled by GNU C version 3.4.0.
; GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
; options passed:  -iprefix -mtune=pentiumpro -auxbase -g
; options enabled:  -feliminate-unused-debug-types -fpeephole
; -ffunction-cse -fkeep-static-consts -fpcc-struct-return -fgcse-lm
; -fgcse-sm -fsched-interblock -fsched-spec -fbranch-count-reg -fcommon
; -fgnu-linker -fargument-alias -fzero-initialized-in-bss -fident
; -fmath-errno -ftrapping-math -m80387 -mhard-float -mno-soft-float
; -mieee-fp -mfp-ret-in-387 -maccumulate-outgoing-args -mno-red-zone
; -mtls-direct-seg-refs -mtune=pentiumpro -march=i386

target triple = "i686-pc-linux-gnu"
target pointersize = 32
target endian = little
deplibs = ["c", "crtend"]

%lldb.compile_unit = type { uint, ushort, ushort, sbyte*, sbyte*, sbyte*, {  }* }
%lldb.global = type { uint, %lldb.compile_unit*, sbyte*, {  }*, sbyte*, bool, bool }
%lldb.local = type { uint, %lldb.global*, sbyte*, sbyte*, bool, bool }
"complex double" = type { double, double }
"complex float" = type { float, float }
"complex long double" = type { double, double }
%llvm.dbg.translation_units = linkonce global {  } {  }

%llvm.dbg.globals = linkonce global {  } {  }

%.str_1 = internal constant [2 x sbyte] c".\00"

%.str_2 = internal constant [12 x sbyte] c"lines.tmp.c\00"

%.str_3 = internal constant [11 x sbyte] c"llvm 3.4.x\00"

%d.compile_unit = internal constant %lldb.compile_unit { uint 17, ushort 0,
ushort 1, sbyte* getelementptr ([12 x sbyte]* %.str_2, int 0, int 0), sbyte*
getelementptr ([2 x sbyte]* %.str_1, int 0, int 0), sbyte* getelementptr ([11 x
sbyte]* %.str_3, int 0, int 0), {  }* %llvm.dbg.translation_units }

%.str_4 = internal constant [2 x sbyte] c"f\00"

%d.f__ = internal global %lldb.global { uint 46, %lldb.compile_unit*
%d.compile_unit, sbyte* getelementptr ([2 x sbyte]* %.str_4, int 0, int 0), { 
}* %llvm.dbg.globals, sbyte* null, bool true, bool false }


implementation
declare {  }* %llvm.dbg.stoppoint({  }*,uint,uint,%lldb.compile_unit*)
declare {  }* %llvm.dbg.func.start(%lldb.global*)
declare {  }* %llvm.dbg.region.start({  }*)
declare {  }* %llvm.dbg.region.end({  }*)
declare {  }* %llvm.dbg.declare({  }*)
declare double %acos(double)  ;; __builtin_acos
declare float %acosf(float)  ;; __builtin_acosf
declare double %acosh(double)  ;; __builtin_acosh
declare float %acoshf(float)  ;; __builtin_acoshf
declare double %acoshl(double)  ;; __builtin_acoshl
declare double %acosl(double)  ;; __builtin_acosl
declare double %asin(double)  ;; __builtin_asin
declare float %asinf(float)  ;; __builtin_asinf
declare double %asinh(double)  ;; __builtin_asinh
declare float %asinhf(float)  ;; __builtin_asinhf
declare double %asinhl(double)  ;; __builtin_asinhl
declare double %asinl(double)  ;; __builtin_asinl
declare double %atan(double)  ;; __builtin_atan
declare double %atan2(double,double)  ;; __builtin_atan2
declare float %atan2f(float,float)  ;; __builtin_atan2f
declare double %atan2l(double,double)  ;; __builtin_atan2l
declare float %atanf(float)  ;; __builtin_atanf
declare double %atanh(double)  ;; __builtin_atanh
declare float %atanhf(float)  ;; __builtin_atanhf
declare double %atanhl(double)  ;; __builtin_atanhl
declare double %atanl(double)  ;; __builtin_atanl
declare double %cbrt(double)  ;; __builtin_cbrt
declare float %cbrtf(float)  ;; __builtin_cbrtf
declare double %cbrtl(double)  ;; __builtin_cbrtl
declare double %ceil(double)  ;; __builtin_ceil
declare float %ceilf(float)  ;; __builtin_ceilf
declare double %ceill(double)  ;; __builtin_ceill
declare double %copysign(double,double)  ;; __builtin_copysign
declare float %copysignf(float,float)  ;; __builtin_copysignf
declare double %copysignl(double,double)  ;; __builtin_copysignl
declare double %cos(double)  ;; __builtin_cos
declare float %cosf(float)  ;; __builtin_cosf
declare double %cosh(double)  ;; __builtin_cosh
declare float %coshf(float)  ;; __builtin_coshf
declare double %coshl(double)  ;; __builtin_coshl
declare double %cosl(double)  ;; __builtin_cosl
declare double %drem(double,double)  ;; __builtin_drem
declare float %dremf(float,float)  ;; __builtin_dremf
declare double %dreml(double,double)  ;; __builtin_dreml
declare double %erf(double)  ;; __builtin_erf
declare double %erfc(double)  ;; __builtin_erfc
declare float %erfcf(float)  ;; __builtin_erfcf
declare double %erfcl(double)  ;; __builtin_erfcl
declare float %erff(float)  ;; __builtin_erff
declare double %erfl(double)  ;; __builtin_erfl
declare double %exp(double)  ;; __builtin_exp
declare double %exp10(double)  ;; __builtin_exp10
declare float %exp10f(float)  ;; __builtin_exp10f
declare double %exp10l(double)  ;; __builtin_exp10l
declare double %exp2(double)  ;; __builtin_exp2
declare float %exp2f(float)  ;; __builtin_exp2f
declare double %exp2l(double)  ;; __builtin_exp2l
declare float %expf(float)  ;; __builtin_expf
declare double %expl(double)  ;; __builtin_expl
declare double %expm1(double)  ;; __builtin_expm1
declare float %expm1f(float)  ;; __builtin_expm1f
declare double %expm1l(double)  ;; __builtin_expm1l
declare double %fabs(double)  ;; __builtin_fabs
declare float %fabsf(float)  ;; __builtin_fabsf
declare double %fabsl(double)  ;; __builtin_fabsl
declare double %fdim(double,double)  ;; __builtin_fdim
declare float %fdimf(float,float)  ;; __builtin_fdimf
declare double %fdiml(double,double)  ;; __builtin_fdiml
declare double %floor(double)  ;; __builtin_floor
declare float %floorf(float)  ;; __builtin_floorf
declare double %floorl(double)  ;; __builtin_floorl
declare double %fma(double,double,double)  ;; __builtin_fma
declare float %fmaf(float,float,float)  ;; __builtin_fmaf
declare double %fmal(double,double,double)  ;; __builtin_fmal
declare double %fmax(double,double)  ;; __builtin_fmax
declare float %fmaxf(float,float)  ;; __builtin_fmaxf
declare double %fmaxl(double,double)  ;; __builtin_fmaxl
declare double %fmin(double,double)  ;; __builtin_fmin
declare float %fminf(float,float)  ;; __builtin_fminf
declare double %fminl(double,double)  ;; __builtin_fminl
declare double %fmod(double,double)  ;; __builtin_fmod
declare float %fmodf(float,float)  ;; __builtin_fmodf
declare double %fmodl(double,double)  ;; __builtin_fmodl
declare double %frexp(double,int*)  ;; __builtin_frexp
declare float %frexpf(float,int*)  ;; __builtin_frexpf
declare double %frexpl(double,int*)  ;; __builtin_frexpl
declare double %gamma(double)  ;; __builtin_gamma
declare float %gammaf(float)  ;; __builtin_gammaf
declare double %gammal(double)  ;; __builtin_gammal
declare double %__builtin_huge_val()
declare float %__builtin_huge_valf()
declare double %__builtin_huge_vall()
declare double %hypot(double,double)  ;; __builtin_hypot
declare float %hypotf(float,float)  ;; __builtin_hypotf
declare double %hypotl(double,double)  ;; __builtin_hypotl
declare int %ilogb(double)  ;; __builtin_ilogb
declare int %ilogbf(float)  ;; __builtin_ilogbf
declare int %ilogbl(double)  ;; __builtin_ilogbl
declare double %__builtin_inf()
declare float %__builtin_inff()
declare double %__builtin_infl()
declare double %j0(double)  ;; __builtin_j0
declare float %j0f(float)  ;; __builtin_j0f
declare double %j0l(double)  ;; __builtin_j0l
declare double %j1(double)  ;; __builtin_j1
declare float %j1f(float)  ;; __builtin_j1f
declare double %j1l(double)  ;; __builtin_j1l
declare double %jn(int,double)  ;; __builtin_jn
declare float %jnf(int,float)  ;; __builtin_jnf
declare double %jnl(int,double)  ;; __builtin_jnl
declare double %ldexp(double,int)  ;; __builtin_ldexp
declare float %ldexpf(float,int)  ;; __builtin_ldexpf
declare double %ldexpl(double,int)  ;; __builtin_ldexpl
declare double %lgamma(double)  ;; __builtin_lgamma
declare float %lgammaf(float)  ;; __builtin_lgammaf
declare double %lgammal(double)  ;; __builtin_lgammal
declare long %llrint(double)  ;; __builtin_llrint
declare long %llrintf(float)  ;; __builtin_llrintf
declare long %llrintl(double)  ;; __builtin_llrintl
declare long %llround(double)  ;; __builtin_llround
declare long %llroundf(float)  ;; __builtin_llroundf
declare long %llroundl(double)  ;; __builtin_llroundl
declare double %log(double)  ;; __builtin_log
declare double %log10(double)  ;; __builtin_log10
declare float %log10f(float)  ;; __builtin_log10f
declare double %log10l(double)  ;; __builtin_log10l
declare double %log1p(double)  ;; __builtin_log1p
declare float %log1pf(float)  ;; __builtin_log1pf
declare double %log1pl(double)  ;; __builtin_log1pl
declare double %log2(double)  ;; __builtin_log2
declare float %log2f(float)  ;; __builtin_log2f
declare double %log2l(double)  ;; __builtin_log2l
declare double %logb(double)  ;; __builtin_logb
declare float %logbf(float)  ;; __builtin_logbf
declare double %logbl(double)  ;; __builtin_logbl
declare float %logf(float)  ;; __builtin_logf
declare double %logl(double)  ;; __builtin_logl
declare int %lrint(double)  ;; __builtin_lrint
declare int %lrintf(float)  ;; __builtin_lrintf
declare int %lrintl(double)  ;; __builtin_lrintl
declare int %lround(double)  ;; __builtin_lround
declare int %lroundf(float)  ;; __builtin_lroundf
declare int %lroundl(double)  ;; __builtin_lroundl
declare double %modf(double,double*)  ;; __builtin_modf
declare float %modff(float,float*)  ;; __builtin_modff
declare double %modfl(double,double*)  ;; __builtin_modfl
declare double %nan(sbyte*)  ;; __builtin_nan
declare float %nanf(sbyte*)  ;; __builtin_nanf
declare double %nanl(sbyte*)  ;; __builtin_nanl
declare double %nans(sbyte*)  ;; __builtin_nans
declare float %nansf(sbyte*)  ;; __builtin_nansf
declare double %nansl(sbyte*)  ;; __builtin_nansl
declare double %nearbyint(double)  ;; __builtin_nearbyint
declare float %nearbyintf(float)  ;; __builtin_nearbyintf
declare double %nearbyintl(double)  ;; __builtin_nearbyintl
declare double %nextafter(double,double)  ;; __builtin_nextafter
declare float %nextafterf(float,float)  ;; __builtin_nextafterf
declare double %nextafterl(double,double)  ;; __builtin_nextafterl
declare double %nexttoward(double,double)  ;; __builtin_nexttoward
declare float %nexttowardf(float,double)  ;; __builtin_nexttowardf
declare double %nexttowardl(double,double)  ;; __builtin_nexttowardl
declare double %pow(double,double)  ;; __builtin_pow
declare double %pow10(double)  ;; __builtin_pow10
declare float %pow10f(float)  ;; __builtin_pow10f
declare double %pow10l(double)  ;; __builtin_pow10l
declare float %powf(float,float)  ;; __builtin_powf
declare double %powl(double,double)  ;; __builtin_powl
declare double %remainder(double,double)  ;; __builtin_remainder
declare float %remainderf(float,float)  ;; __builtin_remainderf
declare double %remainderl(double,double)  ;; __builtin_remainderl
declare double %remquo(double,double,int*)  ;; __builtin_remquo
declare float %remquof(float,float,int*)  ;; __builtin_remquof
declare double %remquol(double,double,int*)  ;; __builtin_remquol
declare double %rint(double)  ;; __builtin_rint
declare float %rintf(float)  ;; __builtin_rintf
declare double %rintl(double)  ;; __builtin_rintl
declare double %round(double)  ;; __builtin_round
declare float %roundf(float)  ;; __builtin_roundf
declare double %roundl(double)  ;; __builtin_roundl
declare double %scalb(double,double)  ;; __builtin_scalb
declare float %scalbf(float,float)  ;; __builtin_scalbf
declare double %scalbl(double,double)  ;; __builtin_scalbl
declare double %scalbln(double,int)  ;; __builtin_scalbln
declare float %scalblnf(float,int)  ;; __builtin_scalblnf
declare double %scalblnl(double,int)  ;; __builtin_scalblnl
declare double %scalbn(double,int)  ;; __builtin_scalbn
declare float %scalbnf(float,int)  ;; __builtin_scalbnf
declare double %scalbnl(double,int)  ;; __builtin_scalbnl
declare double %significand(double)  ;; __builtin_significand
declare float %significandf(float)  ;; __builtin_significandf
declare double %significandl(double)  ;; __builtin_significandl
declare double %sin(double)  ;; __builtin_sin
declare void %sincos(double,double*,double*)  ;; __builtin_sincos
declare void %sincosf(float,float*,float*)  ;; __builtin_sincosf
declare void %sincosl(double,double*,double*)  ;; __builtin_sincosl
declare float %sinf(float)  ;; __builtin_sinf
declare double %sinh(double)  ;; __builtin_sinh
declare float %sinhf(float)  ;; __builtin_sinhf
declare double %sinhl(double)  ;; __builtin_sinhl
declare double %sinl(double)  ;; __builtin_sinl
declare double %sqrt(double)  ;; __builtin_sqrt
declare float %sqrtf(float)  ;; __builtin_sqrtf
declare double %sqrtl(double)  ;; __builtin_sqrtl
declare double %tan(double)  ;; __builtin_tan
declare float %tanf(float)  ;; __builtin_tanf
declare double %tanh(double)  ;; __builtin_tanh
declare float %tanhf(float)  ;; __builtin_tanhf
declare double %tanhl(double)  ;; __builtin_tanhl
declare double %tanl(double)  ;; __builtin_tanl
declare double %tgamma(double)  ;; __builtin_tgamma
declare float %tgammaf(float)  ;; __builtin_tgammaf
declare double %tgammal(double)  ;; __builtin_tgammal
declare double %trunc(double)  ;; __builtin_trunc
declare float %truncf(float)  ;; __builtin_truncf
declare double %truncl(double)  ;; __builtin_truncl
declare double %y0(double)  ;; __builtin_y0
declare float %y0f(float)  ;; __builtin_y0f
declare double %y0l(double)  ;; __builtin_y0l
declare double %y1(double)  ;; __builtin_y1
declare float %y1f(float)  ;; __builtin_y1f
declare double %y1l(double)  ;; __builtin_y1l
declare double %yn(int,double)  ;; __builtin_yn
declare float %ynf(int,float)  ;; __builtin_ynf
declare double %ynl(int,double)  ;; __builtin_ynl
declare double %cabs(double,double)  ;; __builtin_cabs
declare float %cabsf(float,float)  ;; __builtin_cabsf
declare double %cabsl(double,double)  ;; __builtin_cabsl
declare void %cacos("complex double"*,double,double)  ;; __builtin_cacos
declare void %cacosf("complex float"*,float,float)  ;; __builtin_cacosf
declare void %cacosh("complex double"*,double,double)  ;; __builtin_cacosh
declare void %cacoshf("complex float"*,float,float)  ;; __builtin_cacoshf
declare void %cacoshl("complex long double"*,double,double)  ;; __builtin_cacoshl
declare void %cacosl("complex long double"*,double,double)  ;; __builtin_cacosl
declare double %carg(double,double)  ;; __builtin_carg
declare float %cargf(float,float)  ;; __builtin_cargf
declare double %cargl(double,double)  ;; __builtin_cargl
declare void %casin("complex double"*,double,double)  ;; __builtin_casin
declare void %casinf("complex float"*,float,float)  ;; __builtin_casinf
declare void %casinh("complex double"*,double,double)  ;; __builtin_casinh
declare void %casinhf("complex float"*,float,float)  ;; __builtin_casinhf
declare void %casinhl("complex long double"*,double,double)  ;; __builtin_casinhl
declare void %casinl("complex long double"*,double,double)  ;; __builtin_casinl
declare void %catan("complex double"*,double,double)  ;; __builtin_catan
declare void %catanf("complex float"*,float,float)  ;; __builtin_catanf
declare void %catanh("complex double"*,double,double)  ;; __builtin_catanh
declare void %catanhf("complex float"*,float,float)  ;; __builtin_catanhf
declare void %catanhl("complex long double"*,double,double)  ;; __builtin_catanhl
declare void %catanl("complex long double"*,double,double)  ;; __builtin_catanl
declare void %ccos("complex double"*,double,double)  ;; __builtin_ccos
declare void %ccosf("complex float"*,float,float)  ;; __builtin_ccosf
declare void %ccosh("complex double"*,double,double)  ;; __builtin_ccosh
declare void %ccoshf("complex float"*,float,float)  ;; __builtin_ccoshf
declare void %ccoshl("complex long double"*,double,double)  ;; __builtin_ccoshl
declare void %ccosl("complex long double"*,double,double)  ;; __builtin_ccosl
declare void %cexp("complex double"*,double,double)  ;; __builtin_cexp
declare void %cexpf("complex float"*,float,float)  ;; __builtin_cexpf
declare void %cexpl("complex long double"*,double,double)  ;; __builtin_cexpl
declare double %cimag(double,double)  ;; __builtin_cimag
declare float %cimagf(float,float)  ;; __builtin_cimagf
declare double %cimagl(double,double)  ;; __builtin_cimagl
declare void %conj("complex double"*,double,double)  ;; __builtin_conj
declare void %conjf("complex float"*,float,float)  ;; __builtin_conjf
declare void %conjl("complex long double"*,double,double)  ;; __builtin_conjl
declare void %cpow("complex double"*,double,double,double,double)  ;; __builtin_cpow
declare void %cpowf("complex float"*,float,float,float,float)  ;; __builtin_cpowf
declare void %cpowl("complex long double"*,double,double,double,double)  ;;
__builtin_cpowl
declare void %cproj("complex double"*,double,double)  ;; __builtin_cproj
declare void %cprojf("complex float"*,float,float)  ;; __builtin_cprojf
declare void %cprojl("complex long double"*,double,double)  ;; __builtin_cprojl
declare double %creal(double,double)  ;; __builtin_creal
declare float %crealf(float,float)  ;; __builtin_crealf
declare double %creall(double,double)  ;; __builtin_creall
declare void %csin("complex double"*,double,double)  ;; __builtin_csin
declare void %csinf("complex float"*,float,float)  ;; __builtin_csinf
declare void %csinh("complex double"*,double,double)  ;; __builtin_csinh
declare void %csinhf("complex float"*,float,float)  ;; __builtin_csinhf
declare void %csinhl("complex long double"*,double,double)  ;; __builtin_csinhl
declare void %csinl("complex long double"*,double,double)  ;; __builtin_csinl
declare void %csqrt("complex double"*,double,double)  ;; __builtin_csqrt
declare void %csqrtf("complex float"*,float,float)  ;; __builtin_csqrtf
declare void %csqrtl("complex long double"*,double,double)  ;; __builtin_csqrtl
declare void %ctan("complex double"*,double,double)  ;; __builtin_ctan
declare void %ctanf("complex float"*,float,float)  ;; __builtin_ctanf
declare void %ctanh("complex double"*,double,double)  ;; __builtin_ctanh
declare void %ctanhf("complex float"*,float,float)  ;; __builtin_ctanhf
declare void %ctanhl("complex long double"*,double,double)  ;; __builtin_ctanhl
declare void %ctanl("complex long double"*,double,double)  ;; __builtin_ctanl
declare int %bcmp(sbyte*,sbyte*,uint)  ;; __builtin_bcmp
declare void %bcopy(sbyte*,sbyte*,uint)  ;; __builtin_bcopy
declare void %bzero(sbyte*,uint)  ;; __builtin_bzero
declare int %ffs(int)  ;; __builtin_ffs
declare int %ffsl(int)  ;; __builtin_ffsl
declare int %ffsll(long)  ;; __builtin_ffsll
declare sbyte* %index(sbyte*,int)  ;; __builtin_index
declare int %memcmp(sbyte*,sbyte*,uint)  ;; __builtin_memcmp
declare sbyte* %memcpy(sbyte*,sbyte*,uint)  ;; __builtin_memcpy
declare sbyte* %memmove(sbyte*,sbyte*,uint)  ;; __builtin_memmove
declare sbyte* %mempcpy(sbyte*,sbyte*,uint)  ;; __builtin_mempcpy
declare sbyte* %memset(sbyte*,int,uint)  ;; __builtin_memset
declare sbyte* %rindex(sbyte*,int)  ;; __builtin_rindex
declare sbyte* %stpcpy(sbyte*,sbyte*)  ;; __builtin_stpcpy
declare sbyte* %strcat(sbyte*,sbyte*)  ;; __builtin_strcat
declare sbyte* %strchr(sbyte*,int)  ;; __builtin_strchr
declare int %strcmp(sbyte*,sbyte*)  ;; __builtin_strcmp
declare sbyte* %strcpy(sbyte*,sbyte*)  ;; __builtin_strcpy
declare uint %strcspn(sbyte*,sbyte*)  ;; __builtin_strcspn
declare sbyte* %strdup(sbyte*)  ;; __builtin_strdup
declare uint %strlen(sbyte*)  ;; __builtin_strlen
declare sbyte* %strncat(sbyte*,sbyte*,uint)  ;; __builtin_strncat
declare int %strncmp(sbyte*,sbyte*,uint)  ;; __builtin_strncmp
declare sbyte* %strncpy(sbyte*,sbyte*,uint)  ;; __builtin_strncpy
declare sbyte* %strpbrk(sbyte*,sbyte*)  ;; __builtin_strpbrk
declare sbyte* %strrchr(sbyte*,int)  ;; __builtin_strrchr
declare uint %strspn(sbyte*,sbyte*)  ;; __builtin_strspn
declare sbyte* %strstr(sbyte*,sbyte*)  ;; __builtin_strstr
declare int %fprintf(sbyte*,sbyte*, ...)  ;; __builtin_fprintf
declare int %fprintf_unlocked(sbyte*,sbyte*, ...)  ;; __builtin_fprintf_unlocked
declare int %fputc(int,sbyte*)  ;; __builtin_fputc
declare int %fputc_unlocked(int,sbyte*)  ;; __builtin_fputc_unlocked
declare int %fputs(sbyte*,sbyte*)  ;; __builtin_fputs
declare int %fputs_unlocked(sbyte*,sbyte*)  ;; __builtin_fputs_unlocked
declare int %fscanf(sbyte*,sbyte*, ...)  ;; __builtin_fscanf
declare uint %fwrite(sbyte*,uint,uint,sbyte*)  ;; __builtin_fwrite
declare uint %fwrite_unlocked(sbyte*,uint,uint,sbyte*)  ;; __builtin_fwrite_unlocked
declare int %printf(sbyte*, ...)  ;; __builtin_printf
declare int %printf_unlocked(sbyte*, ...)  ;; __builtin_printf_unlocked
declare int %putchar(int)  ;; __builtin_putchar
declare int %putchar_unlocked(int)  ;; __builtin_putchar_unlocked
declare int %puts(sbyte*)  ;; __builtin_puts
declare int %puts_unlocked(sbyte*)  ;; __builtin_puts_unlocked
declare int %scanf(sbyte*, ...)  ;; __builtin_scanf
declare int %snprintf(sbyte*,uint,sbyte*, ...)  ;; __builtin_snprintf
declare int %sprintf(sbyte*,sbyte*, ...)  ;; __builtin_sprintf
declare int %sscanf(sbyte*,sbyte*, ...)  ;; __builtin_sscanf
declare int %vfprintf(sbyte*,sbyte*,sbyte*)  ;; __builtin_vfprintf
declare int %vfscanf(sbyte*,sbyte*,sbyte*)  ;; __builtin_vfscanf
declare int %vprintf(sbyte*,sbyte*)  ;; __builtin_vprintf
declare int %vscanf(sbyte*,sbyte*)  ;; __builtin_vscanf
declare int %vsnprintf(sbyte*,uint,sbyte*,sbyte*)  ;; __builtin_vsnprintf
declare int %vsprintf(sbyte*,sbyte*,sbyte*)  ;; __builtin_vsprintf
declare int %vsscanf(sbyte*,sbyte*,sbyte*)  ;; __builtin_vsscanf
declare void %abort()  ;; __builtin_abort
declare int %abs(int)  ;; __builtin_abs
declare sbyte* %__builtin_aggregate_incoming_address(...)
declare sbyte* %alloca(uint)  ;; __builtin_alloca
declare sbyte* %__builtin_apply(void (...)*,sbyte*,uint)
declare sbyte* %__builtin_apply_args(...)
declare int %__builtin_args_info(int)
declare sbyte* %calloc(uint,uint)  ;; __builtin_calloc
declare int %__builtin_classify_type(...)
declare int %__builtin_clz(int)
declare int %__builtin_clzl(int)
declare int %__builtin_clzll(long)
declare int %__builtin_constant_p(...)
declare int %__builtin_ctz(int)
declare int %__builtin_ctzl(int)
declare int %__builtin_ctzll(long)
declare sbyte* %dcgettext(sbyte*,sbyte*,int)  ;; __builtin_dcgettext
declare sbyte* %dgettext(sbyte*,sbyte*)  ;; __builtin_dgettext
declare sbyte* %__builtin_dwarf_cfa()
declare uint %__builtin_dwarf_sp_column()
declare void %__builtin_eh_return(int,sbyte*)
declare int %__builtin_eh_return_data_regno(int)
declare void %exit(int)  ;; __builtin_exit
declare int %__builtin_expect(int,int)
declare sbyte* %__builtin_extract_return_addr(sbyte*)
declare sbyte* %__builtin_frame_address(uint)
declare sbyte* %__builtin_frob_return_addr(sbyte*)
declare sbyte* %gettext(sbyte*)  ;; __builtin_gettext
declare long %imaxabs(long)  ;; __builtin_imaxabs
declare void %__builtin_init_dwarf_reg_size_table(sbyte*)
declare int %__builtin_isgreater(...)
declare int %__builtin_isgreaterequal(...)
declare int %__builtin_isless(...)
declare int %__builtin_islessequal(...)
declare int %__builtin_islessgreater(...)
declare int %__builtin_isunordered(...)
declare int %labs(int)  ;; __builtin_labs
declare long %llabs(long)  ;; __builtin_llabs
declare void %__builtin_longjmp(sbyte*,int)
declare sbyte* %malloc(uint)  ;; __builtin_malloc
declare sbyte* %__builtin_next_arg(...)
declare int %__builtin_parity(int)
declare int %__builtin_parityl(int)
declare int %__builtin_parityll(long)
declare int %__builtin_popcount(int)
declare int %__builtin_popcountl(int)
declare int %__builtin_popcountll(long)
declare void %__builtin_prefetch(sbyte*, ...)
declare void %__builtin_return(sbyte*)
declare sbyte* %__builtin_return_address(uint)
declare sbyte* %__builtin_saveregs(...)
declare int %__builtin_setjmp(sbyte*)
declare void %__builtin_stdarg_start(sbyte**, ...)
declare int %strfmon(sbyte*,uint,sbyte*, ...)  ;; __builtin_strfmon
declare uint %strftime(sbyte*,uint,sbyte*,sbyte*)  ;; __builtin_strftime
declare void %__builtin_trap()
declare void %__builtin_unwind_init()
declare void %__builtin_va_copy(sbyte**,sbyte*)
declare void %__builtin_va_end(sbyte**)
declare void %__builtin_va_start(sbyte**, ...)
declare void %_exit(int)  ;; __builtin__exit
declare void %_Exit(int)  ;; __builtin__Exit

int %f(int %a) {
entry:
        %a_addr = alloca int             ; ty=int*
        %result = alloca int             ; ty=int*
        %dbg.0 = alloca {  }*            ; ty={  }**
        %dbg.1 = call {  }* (%lldb.global*)* %llvm.dbg.func.start(%lldb.global*
%d.f__)          ; ty={  }*
        store {  }* %dbg.1, {  }** %dbg.0
        store int %a, int* %a_addr
        %dbg.tmp.0 = load {  }** %dbg.0          ; ty={  }*
        %dbg.tmp.1 = call {  }* ({  }*, uint, uint, %lldb.compile_unit*)*
%llvm.dbg.stoppoint({  }* %dbg.tmp.0, uint 0, uint 0, %lldb.compile_unit*
%d.compile_unit)                ; ty={  }*
        store {  }* %dbg.tmp.1, {  }** %dbg.0
        %dbg.tmp.2 = load {  }** %dbg.0          ; ty={  }*
        %dbg.tmp.3 = call {  }* ({  }*, uint, uint, %lldb.compile_unit*)*
%llvm.dbg.stoppoint({  }* %dbg.tmp.2, uint 1, uint 0, %lldb.compile_unit*
%d.compile_unit)                ; ty={  }*
        store {  }* %dbg.tmp.3, {  }** %dbg.0
        %tmp.4 = load int* %a_addr               ; ty=int
        %tmp.5 = load int* %a_addr               ; ty=int
        %tmp.6 = mul int %tmp.4, %tmp.5          ; ty=int
        store int %tmp.6, int* %result
        br label %return
after_ret:
        %dbg.tmp.4 = load {  }** %dbg.0          ; ty={  }*
        %dbg.tmp.5 = call {  }* ({  }*, uint, uint, %lldb.compile_unit*)*
%llvm.dbg.stoppoint({  }* %dbg.tmp.4, uint 2, uint 0, %lldb.compile_unit*
%d.compile_unit)                ; ty={  }*
        store {  }* %dbg.tmp.5, {  }** %dbg.0
        br label %return
return:
        %dbg.tmp.6 = load {  }** %dbg.0          ; ty={  }*
        %dbg.tmp.7 = call {  }* ({  }*)* %llvm.dbg.region.end({  }* %dbg.tmp.6)
         ; ty={  }*
        store {  }* %dbg.tmp.7, {  }** %dbg.0
        %tmp.7 = load int* %result               ; ty=int
        ret int %tmp.7
}

;; Created by "GCC: (GNU) 3.4-llvm 20051104 (LLVM 1.6)"

2. gcc output:

        .file   "lines.tmp.c"
        .section        .debug_abbrev,"", at progbits
.Ldebug_abbrev0:
        .section        .debug_info,"", at progbits
.Ldebug_info0:
        .section        .debug_line,"", at progbits
.Ldebug_line0:
        .text
.Ltext0:
.globl f
        .type   f, @function
f:
.LFB3:
        .file 1 "lines.tmp.c"
        .loc 1 3 0
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        .file 2 "someplace"
        .loc 2 1 0
        movl    8(%ebp), %eax
        imull   8(%ebp), %eax
        .loc 2 2 0
        popl    %ebp
        ret
.LFE3:
        .size   f, .-f
        .section        .debug_frame,"", at progbits
.Lframe0:
        .long   .LECIE0-.LSCIE0
.LSCIE0:
        .long   0xffffffff
        .byte   0x1
        .string ""
        .uleb128 0x1
        .sleb128 -4
        .byte   0x8
        .byte   0xc
        .uleb128 0x4
        .uleb128 0x4
        .byte   0x88
        .uleb128 0x1
        .align 4
.LECIE0:
.LSFDE0:
        .long   .LEFDE0-.LASFDE0
.LASFDE0:
        .long   .Lframe0
        .long   .LFB3
        .long   .LFE3-.LFB3
        .byte   0x4
        .long   .LCFI0-.LFB3
        .byte   0xe
        .uleb128 0x8
        .byte   0x85
        .uleb128 0x2
        .byte   0x4
        .long   .LCFI1-.LCFI0
        .byte   0xd
        .uleb128 0x5
        .align 4
.LEFDE0:
        .text
.Letext0:
        .section        .debug_info
        .long   0x4f
        .value  0x2
        .long   .Ldebug_abbrev0
        .byte   0x4
        .uleb128 0x1
        .long   .Ldebug_line0
        .long   .Letext0
        .long   .Ltext0
        .long   .LC0
        .long   .LC1
        .long   .LC2
        .byte   0x1
        .uleb128 0x2
        .long   0x4b
        .byte   0x1
        .string "f"
        .byte   0x1
        .byte   0x3
        .byte   0x1
        .long   0x4b
        .long   .LFB3
        .long   .LFE3
        .byte   0x1
        .byte   0x55
        .uleb128 0x3
        .string "a"
        .byte   0x1
        .byte   0x2
        .long   0x4b
        .byte   0x2
        .byte   0x91
        .sleb128 8
        .byte   0x0
        .uleb128 0x4
        .string "int"
        .byte   0x4
        .byte   0x5
        .byte   0x0
        .section        .debug_abbrev
        .uleb128 0x1
        .uleb128 0x11
        .byte   0x1
        .uleb128 0x10
        .uleb128 0x6
        .uleb128 0x12
        .uleb128 0x1
        .uleb128 0x11
        .uleb128 0x1
        .uleb128 0x3
        .uleb128 0xe
        .uleb128 0x1b
        .uleb128 0xe
        .uleb128 0x25
        .uleb128 0xe
        .uleb128 0x13
        .uleb128 0xb
        .byte   0x0
        .byte   0x0
        .uleb128 0x2
        .uleb128 0x2e
        .byte   0x1
        .uleb128 0x1
        .uleb128 0x13
        .uleb128 0x3f
        .uleb128 0xc
        .uleb128 0x3
        .uleb128 0x8
        .uleb128 0x3a
        .uleb128 0xb
        .uleb128 0x3b
        .uleb128 0xb
        .uleb128 0x27
        .uleb128 0xc
        .uleb128 0x49
        .uleb128 0x13
        .uleb128 0x11
        .uleb128 0x1
        .uleb128 0x12
        .uleb128 0x1
        .uleb128 0x40
        .uleb128 0xa
        .byte   0x0
        .byte   0x0
        .uleb128 0x3
        .uleb128 0x5
        .byte   0x0
        .uleb128 0x3
        .uleb128 0x8
        .uleb128 0x3a
        .uleb128 0xb
        .uleb128 0x3b
        .uleb128 0xb
        .uleb128 0x49
        .uleb128 0x13
        .uleb128 0x2
        .uleb128 0xa
        .byte   0x0
        .byte   0x0
        .uleb128 0x4
        .uleb128 0x24
        .byte   0x0
        .uleb128 0x3
        .uleb128 0x8
        .uleb128 0xb
        .uleb128 0xb
        .uleb128 0x3e
        .uleb128 0xb
        .byte   0x0
        .byte   0x0
        .byte   0x0
        .section        .debug_pubnames,"", at progbits
        .long   0x14
        .value  0x2
        .long   .Ldebug_info0
        .long   0x53
        .long   0x25
        .string "f"
        .long   0x0
        .section        .debug_aranges,"", at progbits
        .long   0x1c
        .value  0x2
        .long   .Ldebug_info0
        .byte   0x4
        .byte   0x0
        .value  0x0
        .value  0x0
        .long   .Ltext0
        .long   .Letext0-.Ltext0
        .long   0x0
        .long   0x0
        .section        .debug_str,"MS", at progbits,1
.LC0:
        .string "lines.tmp.c"
.LC1:
        .string "/homes/yosefk/phdl/VMP"
.LC2:
        .string "GNU C 3.3.1 (SuSE Linux)"
        .ident  "GCC: (GNU) 3.3.1 (SuSE Linux)"



------- 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 Sep 10 17:49:01 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 10 Sep 2006 17:49:01 -0500
Subject: [LLVMbugs] [Bug 904] #line directives are mishandled in debug info
	generation
Message-ID: <200609102249.k8AMn13Z024291@zion.cs.uiuc.edu>

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

jlaskey at apple.com changed:

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



------- Additional Comments From jlaskey at apple.com  2006-09-10 17:49 -------
Works for llvm-gcc 4.0 (output from dwarfdump and llc -march=c)


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

                Dir  Mod Time   File Len   File Name
                ---- ---------- ---------- ---------------------------
file_names[  1]    1 0x00000000 0x00000000 test.c
file_names[  2]    1 0x00000000 0x00000000 someplace
0x00000051: DW_LNE_set_address( 0x00000000 )
0x00000058: address += 0,  line += 2
            0x0000000000000000      1      3      0

0x00000059: DW_LNE_set_address( 0x00000004 )
0x00000060: DW_LNS_set_file( 2 )
0x00000062: address += 0,  line += -2
            0x0000000000000004      2      1      0

0x00000063: DW_LNE_set_address( 0x00000018 )
0x0000006a: address += 0,  line += 1
            0x0000000000000018      2      2      0

0x0000006b: DW_LNE_set_address( 0x0000001c )
0x00000072: DW_LNE_end_sequence
            0x000000000000001c      2      2      0

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

int f(int ltmp_0_1) {
  int ltmp_1_2;    /* Address-exposed local */
  int ltmp_2_2;    /* Address-exposed local */
  int ltmp_3_2;    /* Address-exposed local */
  int ltmp_4_1;
  struct l_unnamed0 *ltmp_5_3;
  struct l_unnamed0 *ltmp_6_3;
  int ltmp_7_1;
  int ltmp_8_1;
  int ltmp_9_1;
  int ltmp_10_1;

  ltmp_4_1 = (int )0;
  
#line 3 "/Sources/Projects/DwarfTesting/test.c"
;
  ltmp_5_3 = (struct l_unnamed0 *)(&ltmp_1_2);
  *(&ltmp_1_2) = ltmp_0_1;
  ltmp_6_3 = (struct l_unnamed0 *)(&ltmp_2_2);
  
#line 1 "/Sources/Projects/DwarfTesting/someplace"
;
  ltmp_7_1 = *(&ltmp_1_2);
  ltmp_8_1 = *(&ltmp_1_2);
  *(&ltmp_3_2) = (ltmp_7_1*ltmp_8_1);
  ltmp_9_1 = *(&ltmp_3_2);
  *(&ltmp_2_2) = ltmp_9_1;
  ltmp_10_1 = *(&ltmp_2_2);
  
#line 2 "/Sources/Projects/DwarfTesting/someplace"
;
  return ltmp_10_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  Mon Sep 11 12:08:31 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Sep 2006 12:08:31 -0500
Subject: [LLVMbugs] [Bug 792] Factor AsmWriter out of lib/VMCore
Message-ID: <200609111708.k8BH8V7h019713@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2006-09-11 12:08 -------
This shouldn't be resolved, it's not done yet.



------- 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 Sep 11 14:07:08 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Sep 2006 14:07:08 -0500
Subject: [LLVMbugs] [Bug 905] NEW: instcombine assertion error (Invalid
	structure index)
Message-ID: <200609111907.k8BJ786C022355@zion.cs.uiuc.edu>

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

           Summary: instcombine assertion error (Invalid structure index)
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: opt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eric at vanrietpaap.nl


While working on emplementing some new feature in PyPy's LLVM backend (garbage collection 
framework) we encountered a blocker. I've ran bugpoint on it and it came with a rather small reduced 
case, which I have attached. The traceback I get is this:....

opt: Type.cpp:375: virtual const llvm::Type* llvm::StructType::getTypeAtIndex(const llvm::Value*) const: 
Assertion `indexValid(V) && "Invalid structure index!"' failed.
/home/ericvrp/projects/llvm/Release/bin/opt((anonymous 
namespace)::PrintStackTrace()+0x1f)[0x83c7e0f]/lib/libc.so.6(abort+0xeb)[0xb7dc30f3]
/lib/libc.so.6(__assert_fail+0xeb)[0xb7dbb4af]
/home/ericvrp/projects/llvm/Release/bin/opt(llvm::StructType::getTypeAtIndex(llvm::Value const*) 
const+0x6a)[0x837b1fa]
./crash.sh: line 1: 21353 Aborted                 ~/projects/llvm/Release/bin/opt bugpoint-reduced-
simplified.bc -instcombine



------- 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 Sep 11 16:43:56 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Sep 2006 16:43:56 -0500
Subject: [LLVMbugs] [Bug 905] [instcombine] assertion error (Invalid
	structure index) with empty struct
Message-ID: <200609112143.k8BLhuEn025333@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|opt                         |Scalar Optimizations
           Keywords|                            |compile-fail
         OS/Version|Linux                       |All
            Product|tools                       |libraries
           Platform|PC                          |All
         Resolution|                            |FIXED
            Summary|instcombine assertion error |[instcombine] assertion
                   |(Invalid structure index)   |error (Invalid structure
                   |                            |index) with empty struct
   Target Milestone|---                         |1.9
            Version|trunk                       |1.0



------- Additional Comments From sabre at nondot.org  2006-09-11 16:43 -------
Fixed.?? Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060911/037721.html

Testcase here:
Transforms/InstCombine/2006-09-11-EmptyStructCrash.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 Sep 11 17:47:19 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Sep 2006 17:47:19 -0500
Subject: [LLVMbugs] [Bug 906] NEW: llvm-gcc4 crashes on this bitfield
	reference
Message-ID: <200609112247.k8BMlJ4O026374@zion.cs.uiuc.edu>

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

           Summary: llvm-gcc4 crashes on this bitfield reference
           Product: tools
           Version: 1.7
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


struct state_struct {
?? unsigned long long phys_frame: 50;
?? unsigned valid : 2;
} s;

int mem_access(struct state_struct *p) {
?? return p->valid;
}



------- 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 Sep 11 17:49:48 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Sep 2006 17:49:48 -0500
Subject: [LLVMbugs] [Bug 906] llvm-gcc4 crashes on this bitfield reference
Message-ID: <200609112249.k8BMnma8026496@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |code-quality, compile-fail
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-09-11 17:49 -------
Fixed.?? Testcase here:
Regression/CFrontend/2006-09-11-BitfieldRefCrash.c

Patch here:

Index: llvm-convert.cpp
===============================================================
====
--- llvm-convert.cpp?? ?? (revision 117816)
+++ llvm-convert.cpp?? ?? (working copy)
@@ -3704,6 +3704,9 @@
???? }
??
???? if (tree DeclaredType = DECL_BIT_FIELD_TYPE(FieldDecl)) {
+?? ?? const Type *LLVMFieldTy =??
+?? ?? ?? cast<PointerType>(FieldPtr->getType())->getElementType();
+?? ????
???? ?? // If this is a bitfield, the declared type must be an integral type.
???? ?? FieldTy = ConvertType(DeclaredType);
???? ?? // If the field result is a bool, cast to a ubyte instead.?? It is not
@@ -3713,11 +3716,20 @@
???? ?? ?? FieldTy = Type::UByteTy;
???? ?? assert(FieldTy->isInteger() && "Invalid bitfield");
??
+?? ?? // If the LLVM notion of the field type is larger than the actual field type
+?? ?? // being accessed, use the LLVM type.?? This avoids pointer casts and other
+?? ?? // bad things that are difficult to clean up later.?? This occurs in cases
+?? ?? // like "struct X{ unsigned long long x:50; unsigned y:2; }" when accessing
+?? ?? // y.?? We want to access the field as a ulong, not as a uint with an offset.
+?? ?? if (LLVMFieldTy->isInteger() &&
+?? ?? ?? ?? LLVMFieldTy->getPrimitiveSize() > FieldTy->getPrimitiveSize())
+?? ?? ?? FieldTy = LLVMFieldTy;
+?? ????
???? ?? // We are now loading/storing through a casted pointer type, whose??
???? ?? // signedness depends on the signedness of the field.?? Force the field to??
???? ?? // be unsigned.?? This solves performance problems where you have, for??
???? ?? // example:?? struct { int A:1; unsigned B:2; };?? Consider a store to A then
-?? ?? // a store to be.?? In this case, without this conversion, you'd have a??
+?? ?? // a store to B.?? In this case, without this conversion, you'd have a??
???? ?? // store through an int*, followed by a load from a uint*.?? Forcing them
???? ?? // both to uint* allows the store to be forwarded to the load.
???? ?? FieldTy = FieldTy->getUnsignedVersion();


-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 Sep 11 19:06:41 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Sep 2006 19:06:41 -0500
Subject: [LLVMbugs] [Bug 907] NEW: llc compiles many small loops from
	464.h264ref into poor code
Message-ID: <200609120006.k8C06fSq027889@zion.cs.uiuc.edu>

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

           Summary: llc compiles many small loops from 464.h264ref into poor
                    code
           Product: libraries
           Version: 1.5
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


The CBE compiles many small loops from 464.h264ref into single dispatch group units that native PPC 
backend doesn't.  It looks like it may be a combination of LSR and coallescing failures as well as lack of 
counted loops.

Attaching a small .bc file to demonstrate the issue.  Compare codegen for the function between LLC and 
the CBE.

-Chris



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

From isanbard at gmail.com  Mon Sep 11 23:35:30 2006
From: isanbard at gmail.com (Bill Wendling)
Date: Mon, 11 Sep 2006 21:35:30 -0700
Subject: [LLVMbugs] ICE in LLVM GCC4 Front End
Message-ID: <F569B869-6CA5-43DB-A89C-5EA30A7C1CB9@gmail.com>

Hi,

The following program causes the LLVM GCC4 front end to ICE:

struct A {
   virtual ~A();
};

template <typename Ty>
struct B : public A {
   ~B () { delete [] val; }
private:
     Ty* val;
};

template <typename Ty>
struct C : public A {
   C ();
   ~C ();
};

template <typename Ty>
struct D : public A {
     D () {}
   private:
     B<C<Ty> > blocks;
};

template class D<double>;

I'm far from an expert on this area of the code base, so I'm  
submitting this as a proposed fix:

Index: gcc/llvm-convert.cpp
===================================================================
--- gcc/llvm-convert.cpp        (revision 166)
+++ gcc/llvm-convert.cpp        (working copy)
@@ -2189,11 +2189,13 @@
///
Value *TreeToLLVM::EmitPtrBinOp(tree exp, unsigned Opc) {
    Value *LHS = Emit(TREE_OPERAND(exp, 0), 0);
+  const Type *ElTy = cast<PointerType>(LHS->getType())- 
 >getElementType();

    // If this is an expression like (P+4), try to turn this into
    // "getelementptr P, 1".
    if ((Opc == Instruction::Add || Opc == Instruction::Sub) &&
-      TREE_CODE(TREE_OPERAND(exp, 1)) == INTEGER_CST) {
+      TREE_CODE(TREE_OPERAND(exp, 1)) == INTEGER_CST &&
+      !ElTy->isAbstract()) {
      int64_t Offset = getINTEGER_CSTVal(TREE_OPERAND(exp, 1));

      // If POINTER_SIZE is 32-bits, sign extend the offset.
@@ -2201,7 +2203,6 @@
        Offset = (Offset << 32) >> 32;

      // Figure out how large the element pointed to is.
-    const Type *ElTy = cast<PointerType>(LHS->getType())- 
 >getElementType();
      int64_t EltSize = TD.getTypeSize(ElTy);

      // If EltSize exactly divides Offset, then we know that we can  
turn this


From bugzilla-daemon at cs.uiuc.edu  Tue Sep 12 10:08:21 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Sep 2006 10:08:21 -0500
Subject: [LLVMbugs] [Bug 908] NEW: LICM crash,
	"Uses remain whena value is destroyed"
Message-ID: <200609121508.k8CF8L4p020128@zion.cs.uiuc.edu>

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

           Summary: LICM crash, "Uses remain whena value is destroyed"
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


MultiSource/Applications/oggenc picked up a failure in the nightly run. It
appears to be in the loop invariant code motion pass. Here's what happens:

$ ~/llvm/Debug/bin/opt -licm bugpoint-reduced-simplified.bc
WARNING: You're attempting to print out a bytecode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bytecode first-hand, you
can force output with the `-f' option.

While deleting: uint %tmp16.i
Use still stuck around after Def is destroyed:  %exitcond155 = seteq uint 0,
%tmp16.i           ; <bool> [#uses=0]

opt: Value.cpp:59: virtual llvm::Value::~Value(): Assertion `use_begin() ==
use_end() && "Uses remain when a value is destroyed!"' failed.
/home/nicholas/llvm/Debug/bin/opt((anonymous
namespace)::PrintStackTrace()+0x1a)[0x873245c]
/home/nicholas/llvm/Debug/bin/opt((anonymous
namespace)::SignalHandler(int)+0x110)[0x8732720]
[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  Tue Sep 12 14:18:32 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Sep 2006 14:18:32 -0500
Subject: [LLVMbugs] [Bug 908] LICM crash,
	"Uses remain when a value is destroyed"
Message-ID: <200609121918.k8CJIWcv024504@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |compile-fail
         OS/Version|Linux                       |All
           Platform|PC                          |All
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9



------- Additional Comments From sabre at nondot.org  2006-09-12 14:18 -------
Fixed.?? Testcase here:??
Transforms/LICM/2006-09-12-DeadUserOfSunkInstr.ll

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

Thanks!

-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 Sep 12 19:44:54 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Sep 2006 19:44:54 -0500
Subject: [LLVMbugs] [Bug 909] NEW: Assertion failure in DSAA
Message-ID: <200609130044.k8D0iso8030116@zion.cs.uiuc.edu>

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

           Summary: Assertion failure in DSAA
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Interprocedural Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: domagoj at engineer.com


assert(Offset-O < TD.getTypeSize(SubType) && "Offset out of range!");

Test case attached.

Domagoj



------- 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 Sep 13 09:00:07 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Sep 2006 09:00:07 -0500
Subject: [LLVMbugs] [Bug 910] NEW: llvm-gcc: Segmentation fault. ICE on valid
Message-ID: <200609131400.k8DE07dV028956@zion.cs.uiuc.edu>

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

           Summary: llvm-gcc: Segmentation fault. ICE on valid
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


This code came out of the CBE when I was running bugpoint. Amazingly, it crashes
llvm-gcc:

$ llvm-gcc -O0 -emit-llvm 000.c -c -o 000.bc
000.c: In function ???Usage???:
000.c:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.

Here's the code reduced snippet:

struct l_struct_2E_FILE { char x; };
unsigned fwrite(signed char *, unsigned , unsigned , signed char *);
static signed char str301[39];
static void Usage(signed char *ltmp_611_6) {
  struct l_struct_2E_FILE *ltmp_6202_16;
  unsigned ltmp_6203_92;
  ltmp_6203_92 =  /*tail*/ ((unsigned  (*) (signed char *, unsigned , unsigned ,
struct l_struct_2E_FILE *))(void*)fwrite)((&(str301[0u])), 38u, 1u, ltmp_6202_16);
}

It crashes even if you remove the first line defining struct l_struct_2E_FILE,
but then it ceases to be a crash on valid.



------- 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 Sep 13 17:21:20 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Sep 2006 17:21:20 -0500
Subject: [LLVMbugs] [Bug 911] NEW: ICE during compilation of program
Message-ID: <200609132221.k8DMLKdN006007@zion.cs.uiuc.edu>

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

           Summary: ICE during compilation of program
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: isanbard at gmail.com
        ReportedBy: isanbard at gmail.com


This program:

extern void foo();

struct S {
  short        f1[3];
  unsigned int f2 : 1;
};

void bar()
{
  struct S *A;

  if (A->f2)
    foo();
}

gives this error message:

[bwendling:llvm] /Volumes/Dib/devel/llvm/llvm-gcc4.install/bin/llvm-gcc -c bad.cpp -emit-llvm
../../llvm-gcc4.src/gcc/llvm-convert.cpp:3748: failed assertion `ByteAlignment*8 < LLVMValueBitSize 
&& "Unknown overlap case!"'
bad.cpp: In function 'void bar()':
bad.cpp:8: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.



------- 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 Sep 14 13:47:18 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Sep 2006 13:47:18 -0500
Subject: [LLVMbugs] [Bug 912] NEW: valgrind finds error in DSE using
	AliasAnalysis
Message-ID: <200609141847.k8EIlI3N008605@zion.cs.uiuc.edu>

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

           Summary: valgrind finds error in DSE using AliasAnalysis
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


The DSE seems to have some sort of hard to trigger memory error, caught by valgrind:

$ valgrind opt bugpoint-reduced-simplified.bc -dse
==13389== Memcheck, a memory error detector.
==13389== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==13389== Using LibVEX rev 1606, a library for dynamic binary translation.
==13389== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==13389== Using valgrind-3.2.0-Debian, a dynamic binary instrumentation framework.
==13389== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==13389== For more details, rerun with: -v
==13389== 
WARNING: You're attempting to print out a bytecode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bytecode first-hand, you
can force output with the `-f' option.

==13389== Invalid read of size 4
==13389==    at 0x8440A8F: std::equal_to<llvm::Value*>::operator()(llvm::Value*
const&, llvm::Value* const&) const (stl_function.h:200)
==13389==    by 0x85E9319: __gnu_cxx::hashtable<std::pair<llvm::Value* const,
llvm::AliasSet::PointerRec>, llvm::Value*, __gnu_cxx::hash<llvm::Value*>,
std::_Select1st<std::pair<llvm::Value* const, llvm::AliasSet::PointerRec> >,
std::equal_to<llvm::Value*>, std::allocator<llvm::AliasSet::PointerRec>
>::erase(llvm::Value* const&) (hashtable.h:895)
==13389==    by 0x85E937D: __gnu_cxx::hash_map<llvm::Value*,
llvm::AliasSet::PointerRec, __gnu_cxx::hash<llvm::Value*>,
std::equal_to<llvm::Value*>, std::allocator<llvm::AliasSet::PointerRec>
>::erase(llvm::Value* const&) (hash_map:249)
==13389==    by 0x85E6A7E: llvm::AliasSetTracker::remove(llvm::AliasSet&)
(AliasSetTracker.cpp:377)
==13389==    by 0x85E804A: llvm::AliasSetTracker::remove(llvm::LoadInst*)
(AliasSetTracker.cpp:397)
==13389==    by 0x85E8087: llvm::AliasSetTracker::remove(llvm::Instruction*)
(AliasSetTracker.cpp:430)
==13389==    by 0x850CA62: (anonymous
namespace)::DSE::runOnBasicBlock(llvm::BasicBlock&) (DeadStoreElimination.cpp:108)
==13389==    by 0x850D408: (anonymous
namespace)::DSE::runOnFunction(llvm::Function&) (DeadStoreElimination.cpp:39)
==13389==    by 0x86B9796:
llvm::FunctionPassManagerT::runPass(llvm::FunctionPass*, llvm::Function*)
(PassManagerT.h:804)
==13389==    by 0x86CEF5F:
llvm::PassManagerT<llvm::FTraits>::runPasses(llvm::Function*,
std::map<llvm::Pass*, std::vector<llvm::Pass*, std::allocator<llvm::Pass*> >,
std::less<llvm::Pass*>, std::allocator<std::pair<llvm::Pass* const,
std::vector<llvm::Pass*, std::allocator<llvm::Pass*> > > > >&) (PassManagerT.h:596)
==13389==    by 0x86CF96F:
llvm::PassManagerT<llvm::FTraits>::runOnUnit(llvm::Function*) (PassManagerT.h:282)
==13389==    by 0x86B9878:
llvm::FunctionPassManagerT::runOnFunction(llvm::Function&) (PassManagerT.h:896)
==13389==  Address 0x73470FC is 4 bytes inside a block of size 24 free'd
==13389==    at 0x53FC422: operator delete(void*) (vg_replace_malloc.c:244)
==13389==    by 0x8417ABE:
__gnu_cxx::new_allocator<__gnu_cxx::_Hashtable_node<std::pair<llvm::Value*
const, llvm::AliasSet::PointerRec> >
>::deallocate(__gnu_cxx::_Hashtable_node<std::pair<llvm::Value* const,
llvm::AliasSet::PointerRec> >*, unsigned) (new_allocator.h:94)
==13389==    by 0x8417AE3: __gnu_cxx::hashtable<std::pair<llvm::Value* const,
llvm::AliasSet::PointerRec>, llvm::Value*, __gnu_cxx::hash<llvm::Value*>,
std::_Select1st<std::pair<llvm::Value* const, llvm::AliasSet::PointerRec> >,
std::equal_to<llvm::Value*>, std::allocator<llvm::AliasSet::PointerRec>
>::_M_put_node(__gnu_cxx::_Hashtable_node<std::pair<llvm::Value* const,
llvm::AliasSet::PointerRec> >*) (hashtable.h:301)
==13389==    by 0x8417B33: __gnu_cxx::hashtable<std::pair<llvm::Value* const,
llvm::AliasSet::PointerRec>, llvm::Value*, __gnu_cxx::hash<llvm::Value*>,
std::_Select1st<std::pair<llvm::Value* const, llvm::AliasSet::PointerRec> >,
std::equal_to<llvm::Value*>, std::allocator<llvm::AliasSet::PointerRec>
>::_M_delete_node(__gnu_cxx::_Hashtable_node<std::pair<llvm::Value* const,
llvm::AliasSet::PointerRec> >*) (hashtable.h:623)
==13389==    by 0x85E92B2: __gnu_cxx::hashtable<std::pair<llvm::Value* const,
llvm::AliasSet::PointerRec>, llvm::Value*, __gnu_cxx::hash<llvm::Value*>,
std::_Select1st<std::pair<llvm::Value* const, llvm::AliasSet::PointerRec> >,
std::equal_to<llvm::Value*>, std::allocator<llvm::AliasSet::PointerRec>
>::erase(llvm::Value* const&) (hashtable.h:884)
==13389==    by 0x85E937D: __gnu_cxx::hash_map<llvm::Value*,
llvm::AliasSet::PointerRec, __gnu_cxx::hash<llvm::Value*>,
std::equal_to<llvm::Value*>, std::allocator<llvm::AliasSet::PointerRec>
>::erase(llvm::Value* const&) (hash_map:249)
==13389==    by 0x85E6A7E: llvm::AliasSetTracker::remove(llvm::AliasSet&)
(AliasSetTracker.cpp:377)
==13389==    by 0x85E804A: llvm::AliasSetTracker::remove(llvm::LoadInst*)
(AliasSetTracker.cpp:397)
==13389==    by 0x85E8087: llvm::AliasSetTracker::remove(llvm::Instruction*)
(AliasSetTracker.cpp:430)
==13389==    by 0x850CA62: (anonymous
namespace)::DSE::runOnBasicBlock(llvm::BasicBlock&) (DeadStoreElimination.cpp:108)
==13389==    by 0x850D408: (anonymous
namespace)::DSE::runOnFunction(llvm::Function&) (DeadStoreElimination.cpp:39)
==13389==    by 0x86B9796:
llvm::FunctionPassManagerT::runPass(llvm::FunctionPass*, llvm::Function*)
(PassManagerT.h:804)
==13389== 
==13389== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 27 from 1)
==13389== malloc/free: in use at exit: 99,867 bytes in 1,003 blocks.
==13389== malloc/free: 18,318 allocs, 17,315 frees, 614,957 bytes allocated.
==13389== For counts of detected errors, rerun with: -v
==13389== searching for pointers to 1,003 not-freed blocks.
==13389== checked 415,884 bytes.
==13389== 
==13389== LEAK SUMMARY:
==13389==    definitely lost: 99,608 bytes in 995 blocks.
==13389==      possibly lost: 43 bytes in 1 blocks.
==13389==    still reachable: 216 bytes in 7 blocks.
==13389==         suppressed: 0 bytes in 0 blocks.
==13389== Use --leak-check=full to see details of leaked memory.



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

From babic.domagoj at gmail.com  Thu Sep 14 20:40:45 2006
From: babic.domagoj at gmail.com (Domagoj Babic)
Date: Thu, 14 Sep 2006 18:40:45 -0700
Subject: [LLVMbugs] DSAA patch
Message-ID: <e3684ba30609141840t799f0d6u3b6a2b2a8b758f34@mail.gmail.com>

Several minor modifications:
- dumps to std::cerr that were not guarded by DEBUG() are commented out
- introduced -dsa-no-warn hidden option that disables complains about unknown
  functions (disabled by default)
- added debug intrinsics to Local.cpp:visitCallSite as NOP

The patch compiles and runs fine (tested on cca 30 open source projects with
cca 2 MLOC of C code)

Domagoj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_060912.bz2
Type: application/x-bzip2
Size: 2341 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmbugs/attachments/20060914/9119e23d/attachment.bz2 

From bugzilla-daemon at cs.uiuc.edu  Fri Sep 15 20:00:47 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Sep 2006 20:00:47 -0500
Subject: [LLVMbugs] [Bug 913] NEW: instcombine misoptimizes shr+and to setgt
Message-ID: <200609160100.k8G10l71022833@zion.cs.uiuc.edu>

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

           Summary: instcombine misoptimizes shr+and to setgt
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


The instruction combiner is making the following transformation:

        %tmp = load int* %tmp1          ; <int> [#uses=1]
        %tmp = cast int %tmp to uint            ; <uint> [#uses=1]
-       %tmp2 = shr uint %tmp, ubyte 5          ; <uint> [#uses=1]
-       %tmp2 = cast uint %tmp2 to int          ; <int> [#uses=1]
-       %tmp3 = and int %tmp2, 1                ; <int> [#uses=1]
-       %tmp3 = cast int %tmp3 to bool          ; <bool> [#uses=1]
-       %tmp34 = cast bool %tmp3 to int         ; <int> [#uses=1]
+       %tmp3 = setgt uint %tmp, 31             ; <bool> [#uses=1]
+       %tmp34 = cast bool %tmp3 to int         ; <int> [#uses=2]

simplifying "(x >> 5) & 1 != 0" into "x > 31". They are not the same; consider
64: 64 >> 5 = 2, 2 & 1 = 0. But 64 > 31.



------- 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 Sep 15 22:17:14 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Sep 2006 22:17:14 -0500
Subject: [LLVMbugs] [Bug 913] instcombine misoptimizes shr+and to setgt
Message-ID: <200609160317.k8G3HEDa024984@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |miscompilation
         OS/Version|Linux                       |All
           Platform|PC                          |All
         Resolution|                            |FIXED
   Target Milestone|---                         |1.9
            Version|trunk                       |1.7



------- Additional Comments From sabre at nondot.org  2006-09-15 22:17 -------
Fixed.  Testcase here: Transforms/InstCombine/2006-09-15-CastToBool.ll

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

BTW, instcombine now reduces the function in the testcase to:

int %test(int* %tmp1) {
        %tmp = load int* %tmp1          ; <int> [#uses=1]
        %tmp = cast int %tmp to uint            ; <uint> [#uses=1]
        %tmp2 = shr uint %tmp, ubyte 5          ; <uint> [#uses=1]
        %tmp2 = cast uint %tmp2 to int          ; <int> [#uses=1]
        %tmp34 = and int %tmp2, 1               ; <int> [#uses=1]
        ret int %tmp34
}

The shift is required because the function is required to deliver int 1/0, not a bool.

Thanks!

-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  Sat Sep 16 02:44:58 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Sep 2006 02:44:58 -0500
Subject: [LLVMbugs] [Bug 914] NEW: quantum_toffoli in 462.libquantum
	compiles to really bad code with llc
Message-ID: <200609160744.k8G7iwAM005351@zion.cs.uiuc.edu>

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

           Summary: quantum_toffoli in 462.libquantum compiles to really bad
                    code with llc
           Product: libraries
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


The X86 backend produces significantly slower (2.5x) code for the quantum_toffoli than the C backend.  

Code layout seems to be a major contributing factor, but also there are a number of 64-bit shifts that we 
may be codegen'ing poorly or something.

-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  Sun Sep 17 11:24:43 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 17 Sep 2006 11:24:43 -0500
Subject: [LLVMbugs] [Bug 912] valgrind finds error in DSE using AliasAnalysis
Message-ID: <200609171624.k8HGOh2o011274@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

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



------- Additional Comments From nicholas at mxc.ca  2006-09-17 11:24 -------
Fixed. No testcase because this is a memory management bug.

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060911/037931.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 Sep 18 00:34:00 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Sep 2006 00:34:00 -0500
Subject: [LLVMbugs] [Bug 914] quantum_toffoli in 462.libquantum compiles to
	really bad code with llc
Message-ID: <200609180534.k8I5Y0TR024298@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2006-09-18 00:33 -------
The code layout and instcombine issues are now fixed, 462.libquantum is now 16% faster with llc than 
with 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  Mon Sep 18 13:09:10 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Sep 2006 13:09:10 -0500
Subject: [LLVMbugs] [Bug 910] crash on cast of fwrite address
Message-ID: <200609181809.k8II9A92015059@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |compile-fail
         OS/Version|Linux                       |All
           Platform|PC                          |All
         Resolution|                            |FIXED
            Summary|llvm-gcc: Segmentation      |crash on cast of fwrite
                   |fault. ICE on valid         |address
   Target Milestone|---                         |1.9
            Version|trunk                       |1.7



------- Additional Comments From sabre at nondot.org  2006-09-18 13:09 -------
Fixed.?? Testcase here:
Regression/CFrontend/2006-09-18-fwrite-cast-crash.c

Patch applied to llvm-gcc svn.

-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 Sep 18 15:20:24 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Sep 2006 15:20:24 -0500
Subject: [LLVMbugs] [Bug 915] NEW: internal compiler error in
	lhd_set_decl_assembler_name with nested functions
Message-ID: <200609182020.k8IKKOZ0017617@zion.cs.uiuc.edu>

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

           Summary: internal compiler error in lhd_set_decl_assembler_name
                    with nested functions
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jackrobi at gmail.com


$ /usr/local/llvm/cfrontend/install/bin/llvm-gcc --emit-llvm -S foo.i -fnested-functions 
foo.i: In function ?b?:
foo.i:3: internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:193
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.
$ cat foo.i
static void a() {
  int foo;
  inline void b() {
    foo = -1;
  }
  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  Tue Sep 19 17:00:29 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Sep 2006 17:00:29 -0500
Subject: [LLVMbugs] [Bug 916] NEW: llvm-gcc4 doesn't build on ppc-linux
Message-ID: <200609192200.k8JM0TU1026766@zion.cs.uiuc.edu>

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

           Summary: llvm-gcc4 doesn't build on ppc-linux
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


The compile error is from stor-layout.c using the ADJUST_FIELD_ALIGN macro. It
only has 2 parameters, but the caller is passing 3.

This macro was changed by Apple to put add a third parameter. For example, this
is the definition in gcc/config/i386/i386.h:

/* APPLE LOCAL Macintosh alignment */
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED, FIRST_FIELD_P) \
   x86_field_alignment (FIELD, COMPUTED)
#endif

There's also a definition in gcc/config/rs6000/darwin.h:

/* APPLE LOCAL begin Macintosh alignment 2002-2-26 --ff */
/* This now supports the Macintosh power, mac68k, and natural 
   alignment modes.  It now has one more parameter than the standard 
   version of the ADJUST_FIELD_ALIGN macro.  
   
   The macro works as follows: We use the computed alignment of the 
   field if we are in the natural alignment mode or if the field is 
   a vector.  Otherwise, if we are in the mac68k alignment mode, we
   use the minimum of the computed alignment and 16 (pegging at
   2-byte alignment).  If we are in the power mode, we peg at 32
   (word alignment) unless it is the first field of the struct, in 
   which case we use the computed alignment.  */
#undef ADJUST_FIELD_ALIGN
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED, FIRST_FIELD_P)      \
  (TARGET_ALIGN_NATURAL ? (COMPUTED) :                          \
   (((COMPUTED) == RS6000_VECTOR_ALIGNMENT)                     \
    ? RS6000_VECTOR_ALIGNMENT                                   \
    : (MIN ((COMPUTED),                                         \
            (TARGET_ALIGN_MAC68K ? 16                           \
                                 : ((FIRST_FIELD_P) ? (COMPUTED) \
                                                    : 32))))))

Presumably gcc/config/rs6000/linux.h and linux64.h could have similar macros
defined. Or, whatever two-parameter ADJUST_FIELD_ALIGN which is being redefined
 here could be fixed, but I don't know what file that's in.



------- 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 Sep 20 12:39:54 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Sep 2006 12:39:54 -0500
Subject: [LLVMbugs] [Bug 917] NEW: Fix PowerPC function stub generation for
	distant functions
Message-ID: <200609201739.k8KHdswB027630@zion.cs.uiuc.edu>

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

           Summary: Fix PowerPC function stub generation for distant
                    functions
           Product: libraries
           Version: 1.5
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


In the JIT, stubs are currently used for two purposes:  1. lazy compilation of functions, and 2. calls to 
functions that are beyond the branch displacement supported by the target.

Currently, the target-independent code that runs the JIT (in JIT/JITEmitter.cpp) manages stub 
generation for 2) for the PPC backend.  It does this with the "DoesntNeedStub" mechanism.  This is 
broken for a couple of reasons.  First, this probably breaks the ELF/macho writers, which have to deal 
with this stuff in totally different ways.  Second, this breaks clients that take random function pointers 
and stuff them into the global mapping.

A better solution for 2) would be to have the target JIT-specific "relocate" method emit function stubs if 
the relocation is out of range.  This gets the code for 2) into the target-specific JIT code, where it 
belongs, fixing both #1 and #2.

-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 Sep 20 13:55:53 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Sep 2006 13:55:53 -0500
Subject: [LLVMbugs] [Bug 918] NEW: c backend with array types can produce
	code rejected by gcc 4.0.1
Message-ID: <200609201855.k8KItrlR029260@zion.cs.uiuc.edu>

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

           Summary: c backend with array types can produce code rejected by
                    gcc 4.0.1
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: C
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pedronis at strakt.com


The C backend can currently (recent head) produce code with such patterns:

/* Global Declarations */
/* Structure forward decls */
struct l_structtype_s;

/* Typedefs */
typedef struct l_structtype_s l_fixarray_array3[3]; /* problematic 
declaration */
typedef struct l_structtype_s l_structtype_s;

/* Structure contents */
struct l_structtype_s {
  int field0;
};

gcc 4.0.1 will reject this with a "array type has incomplete element type" error.

this seems not valid C, precedently gcc accepted it as a (fragile) extension.



------- 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 Sep 20 18:57:37 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Sep 2006 18:57:37 -0500
Subject: [LLVMbugs] [Bug 919] NEW: Eliminate llvm-test --with-program=xxx
	options for externals
Message-ID: <200609202357.k8KNvbZ4003662@zion.cs.uiuc.edu>

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

           Summary: Eliminate llvm-test --with-program=xxx options for
                    externals
           Product: Test Suite
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Programs Tests
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


The llvm-test configure option --with-externals is sufficient and widely used.  We should
eliminate the --with-nurbs, --with-fpgrowth, --with-sweep3d, --with-namd, --with-spec2006, etc 
options.

-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 Sep 20 22:46:09 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Sep 2006 22:46:09 -0500
Subject: [LLVMbugs] [Bug 920] NEW: llvm-db should expose that trick where we
	view the CFG
Message-ID: <200609210346.k8L3k9vK007227@zion.cs.uiuc.edu>

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

           Summary: llvm-db should expose that trick where we view the CFG
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: llvm-db
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca


The Function::viewCFG API is a fantastic debugging method for when the developer
is inside a Pass. It'd be nice to expose this in a user-friendly manner to just
examine the contents of a given .bc file, such as a bugpoint reduced testcase.
It could be llvm-db's killer feature. ;-)



------- 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 Sep 20 23:22:38 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Sep 2006 23:22:38 -0500
Subject: [LLVMbugs] [Bug 920] llvm-db should expose that trick where we view
	the CFG
Message-ID: <200609210422.k8L4McfM007865@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2006-09-20 23:22 -------
llvm-db is supposed to be a debugger, but is sorta of neutered right now.

What you want is "opt -analyze -print-cfg foo.bc" and "opt -analyze -print-cfg-only foo.bc".

This will print out a dot file which is viewable with standard techniques.

-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 Sep 22 00:37:15 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Sep 2006 00:37:15 -0500
Subject: [LLVMbugs] [Bug 855] ICE on invalid array with size determined by
	sizeof incomplete type
Message-ID: <200609220537.k8M5bFp4014760@zion.cs.uiuc.edu>

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

isanbard at gmail.com changed:

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



------- Additional Comments From isanbard at gmail.com  2006-09-22 00:37 -------
Fixed:

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

Also patched llvm-gcc.



------- 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 Sep 22 16:01:15 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Sep 2006 16:01:15 -0500
Subject: [LLVMbugs] [Bug 921] NEW: Assertion fails in SelectionDAGIsel.cpp
Message-ID: <200609222101.k8ML1Fhj008138@zion.cs.uiuc.edu>

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

           Summary: Assertion fails in SelectionDAGIsel.cpp
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru


When compiling simple .c file with llvm-gcc & enabled optimizations I have the
folowing assertion:

llc: /home/asl/proj/llvm/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:2137:
void llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallInst&): Assertion
`!Regs.Regs.empty() && "Couldn't allocate output reg!"' failed.

Please find attached files:

1. Source .c file
2. Compiled .bc file via "llvm-gcc -O1", everything is ok with optimizations
disabled.

Steps to reproduce:
1. Run llc -march=x86 round.bc



------- 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 Sep 22 16:23:14 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Sep 2006 16:23:14 -0500
Subject: [LLVMbugs] [Bug 921] Assertion fails in SelectionDAGIsel.cpp
Message-ID: <200609222123.k8MLNEtr008576@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2006-09-22 16:23 -------
This is a duplicate of Bug??879.?? Please see it for a workaround.

-Chris


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



------- 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 Sep 24 13:02:47 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 24 Sep 2006 13:02:47 -0500
Subject: [LLVMbugs] [Bug 807] perform substitution when equality is known
Message-ID: <200609241802.k8OI2lK0031162@zion.cs.uiuc.edu>

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

nicholas at mxc.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |new-feature
         Resolution|                            |FIXED



------- Additional Comments From nicholas at mxc.ca  2006-09-24 13:02 -------
This optimization pass has since been enabled.



------- 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 Sep 25 13:04:47 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Sep 2006 13:04:47 -0500
Subject: [LLVMbugs] [Bug 922] NEW: llvm-gcc3 determines source filename
	incorrectly for errors and debug info
Message-ID: <200609251804.k8PI4laO000402@zion.cs.uiuc.edu>

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

           Summary: llvm-gcc3 determines source filename incorrectly for
                    errors and debug info
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: criswell at uiuc.edu


The llvm-gcc3 frontend (based on GCC 3.4 sources) does not correctly determine
the source filename for C constructs under certain conditions.  This leads to
two errors:

1) Warning and error messages alert the user to look at the wrong file.
2) LLVM debugging instructions contain the wrong filename.



------- 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 Sep 25 13:13:39 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Sep 2006 13:13:39 -0500
Subject: [LLVMbugs] [Bug 922] llvm-gcc3 determines source filename
	incorrectly for errors and debug info
Message-ID: <200609251813.k8PIDdTB000635@zion.cs.uiuc.edu>

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

criswell at uiuc.edu changed:

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



------- Additional Comments From criswell at uiuc.edu  2006-09-25 13:13 -------
Fixed with
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060925/038118.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 Sep 25 13:20:07 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Sep 2006 13:20:07 -0500
Subject: [LLVMbugs] [Bug 923] NEW: adce causes crash in
	PostDominanceFrontier or vice versa
Message-ID: <200609251820.k8PIK7t5000776@zion.cs.uiuc.edu>

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

           Summary: adce causes crash in PostDominanceFrontier or vice versa
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alenhar2 at uiuc.edu


opt bugpoint-reduced-simplified.bc -adce



------- 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 Sep 26 13:41:28 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Sep 2006 13:41:28 -0500
Subject: [LLVMbugs] [Bug 924] NEW: Unsupported inline assembly statement
Message-ID: <200609261841.k8QIfSTD002699@zion.cs.uiuc.edu>

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

           Summary: Unsupported inline assembly statement
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alenhar2 at uiuc.edu


This is a reduction from the linux kernel (gcc is happy with it, llvm-gcc isn't):

void bar() {
        asm volatile ("xorl %eax, %eax; movl %eax, %fs; movl %eax, %gs");
}



------- 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 Sep 27 01:26:59 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Sep 2006 01:26:59 -0500
Subject: [LLVMbugs] [Bug 925] NEW: sdisel lowers this to really bad code
Message-ID: <200609270626.k8R6QxjJ013840@zion.cs.uiuc.edu>

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

           Summary: sdisel lowers this to really bad code
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


In the stupid contrived testcase below, sdisel is breaking *every* critical edge from the switch to the 
blahaha block, creating a ton of duplicated code and making switch lowering uglier than it should be.

void foo(int C) {
  const char *s = "blah";

  switch (C) {
  case 1 ... 10:
    s = "bonk";
    goto blahaha;
  }
  s = "bork";
  if (C & 123)  s = "perfwap";

blahaha:
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
  printf(s);
}

We end up with code like this:

LBB1_1: #entry.blahaha_crit_edge9
        movl $_str1, %esi
        jmp LBB1_14     #blahaha
LBB1_2: #entry.blahaha_crit_edge8
        movl $_str1, %esi
        jmp LBB1_14     #blahaha
LBB1_3: #entry.blahaha_crit_edge7
        movl $_str1, %esi
        jmp LBB1_14     #blahaha
LBB1_4: #entry.blahaha_crit_edge6
        movl $_str1, %esi
        jmp LBB1_14     #blahaha
LBB1_5: #entry.blahaha_crit_edge5
        movl $_str1, %esi
        jmp LBB1_14     #blahaha
...

When splitting critical edges into a block, SDIsel should factor all edges from a particular BB into a 
single split block. 

-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 Sep 27 01:35:15 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Sep 2006 01:35:15 -0500
Subject: [LLVMbugs] [Bug 926] NEW: sdisel switch lowering can be improved
Message-ID: <200609270635.k8R6ZF2f013998@zion.cs.uiuc.edu>

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

           Summary: sdisel switch lowering can be improved
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


First, the trivial thing: a switch lowered to a series of conditional branches always results in an explicit 
"fallthrough" uncond branch to the next block from the initial block.  This is probably a minor book-
keeping bug:

        cmpl $6, %eax
        jl LBB1_20      #entry
***   jmp LBB1_15     #entry
LBB1_15:        #entry


More significantly, we should change the heuristic of the switch lowering a bit.  Specifically, right now, 
at the top level, we decide whether to lower the switch to a series of branches or to a table jump.  I 
think we should always go through the "branch sequence" code path, but make it a bit more 
sophisticated.

In particular, the worklist should start out with a single record with all the case ranges on it.  Each time 
through the loop, a range is popped off.  If the range satisfies the conditions for a tbljmp, emit one.  
Otherwise, split in half and emit a branch to choose between the two.

This would allow us to handle switches with dense portions that are spread out (e.g. 0...100  + 
2000...2100) as two separate tbljump pieces.

This would also make it more natural to plug in other heuristics.  For example, perlbmk has a switch 
that looks like this:
        switch uint %tmp158, label %bb336 [
                 uint 0, label %bb338
                 uint 1, label %bb338
                 uint 2, label %bb338
                 uint 3, label %bb338
                 uint 4, label %bb338
                 uint 5, label %bb338
                 uint 6, label %bb338
                 uint 7, label %bb
                 uint 8, label %bb338
                 uint 9, label %bb322
                 uint 10, label %bb324
                 uint 11, label %bb326
                 uint 12, label %bb328
                 uint 13, label %bb330
                 uint 14, label %bb332
                 uint 15, label %bb334
...

When emitted as a branch tree, the leaves end up doing lots of work to discriminate between the 0->6 
cases, when they all go to the same place.

Another nice xform is to do the "shift/and" technique for switches.

-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 Sep 27 13:17:58 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Sep 2006 13:17:58 -0500
Subject: [LLVMbugs] [Bug 923] PostDominanceFrontier crash
Message-ID: <200609271817.k8RIHwpv011436@zion.cs.uiuc.edu>

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

dpatel at apple.com changed:

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



------- Additional Comments From dpatel at apple.com  2006-09-27 13:17 -------
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060925/038155.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 Sep 27 14:04:57 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Sep 2006 14:04:57 -0500
Subject: [LLVMbugs] [Bug 927] NEW: Get Rid Of Annotations
Message-ID: <200609271904.k8RJ4vPl012494@zion.cs.uiuc.edu>

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

           Summary: Get Rid Of Annotations
           Product: libraries
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


We should get rid of Annotable and Annotation in llvm/Support/Annotation.h.  We
continue get misuse of this feature and questions about it. Such as:
On Wed, 2006-09-27 at 12:36 -0700, Chris Lattner wrote:
On Tue, 26 Sep 2006, Bram Adams wrote:
> >
> > A limitation here is that only Functions' debug data can be kept, as
> > other Values (i.e. Instructions) are not Annotable. Is this an explicit
> > design decision?
> 
> Yes, we intentionally do not want things to be annotatable.  In fact, 
> Function being annotatable is a wart due to the way the code generator 
> currently works.  In general, we prefer to keep data in on-the-side maps 
> instead of attached to the IR.  The mailing list has archives of extensive 
> discussion about this sort of thing.



------- 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 Sep 27 17:06:16 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Sep 2006 17:06:16 -0500
Subject: [LLVMbugs] [Bug 928] NEW: Investigate cases where running llvm
	optimizer twice slows down code
Message-ID: <200609272206.k8RM6Gvm015688@zion.cs.uiuc.edu>

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

           Summary: Investigate cases where running llvm optimizer twice
                    slows down code
           Product: tools
           Version: 1.7
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


These two nightly tester tests:

http://llvm.org/nightlytest/test.php?machine=36&night=1063
http://llvm.org/nightlytest/test.php?machine=23&night=1064

Capture performance changes that were due to running llvm-gcc at -O0 instead of -O2.  The basic 
impact is that we're now runing 'gccas' once instead of twice on the input programs (far more realistic).

Some of these programs got slower, e.g. fldry.  This turns out to be a phase-ordering issue.  If these 
can be tracked down and improved, that would be good.

More important, however, are the programs that sped up by disabling the run of the optimizer.  This 
implies that running the optimizer twice on the programs actually *slowed them down*, which is clearly 
bad.

-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 Sep 27 19:00:15 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Sep 2006 19:00:15 -0500
Subject: [LLVMbugs] [Bug 900] llvm-testresults email needs significant
	improvement
Message-ID: <200609280000.k8S00FT6017489@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

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



------- Additional Comments From sabre at nondot.org  2006-09-27 19:00 -------
Jim took care of this.  Thanks Jim!

-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 Sep 28 02:12:53 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Sep 2006 02:12:53 -0500
Subject: [LLVMbugs] [Bug 878] N^2 (or worse) algorithms in phi elimination
	and livevars
Message-ID: <200609280712.k8S7CrOn028500@zion.cs.uiuc.edu>

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

isanbard at gmail.com changed:

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



------- Additional Comments From isanbard at gmail.com  2006-09-28 02:12 -------
REALLY fixed with this patch:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060925/038173.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  Thu Sep 28 12:40:08 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Sep 2006 12:40:08 -0500
Subject: [LLVMbugs] [Bug 929] NEW: livevars takes 50% of codegen time (N^2
	algorithm?)
Message-ID: <200609281740.k8SHe8jX012952@zion.cs.uiuc.edu>

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

           Summary: livevars takes 50% of codegen time (N^2 algorithm?)
           Product: libraries
           Version: 1.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


Livevars takes 50% of the compile time on the testcase in PR878 (now that Bill fixed the issue in phielim).  
Livevars is probably doing something algorithmically wrong, which should be investigated.

-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 Sep 28 13:59:58 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Sep 2006 13:59:58 -0500
Subject: [LLVMbugs] [Bug 924] Non-extended inline assembly statements should
	have asmstrings interpreted
Message-ID: <200609281859.k8SIxwM4014524@zion.cs.uiuc.edu>

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

sabre at nondot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |compile-fail
         OS/Version|Linux                       |All
           Platform|PC                          |All
         Resolution|                            |FIXED
            Summary|Unsupported inline assembly |Non-extended inline assembly
                   |statement                   |statements should have
                   |                            |asmstrings interpreted
   Target Milestone|---                         |1.9
            Version|trunk                       |1.7



------- Additional Comments From sabre at nondot.org  2006-09-28 13:59 -------
Fixed.  Testcase here:
Regression/CFrontend/2006-09-28-SimpleAsm.c

Patch here:

===============================================================
====
--- llvm-convert.cpp    (revision 118365)
+++ llvm-convert.cpp    (working copy)
@@ -2443,6 +2443,20 @@
   tree str = ASM_STRING(exp);
   if (TREE_CODE(str) == ADDR_EXPR) str = TREE_OPERAND(str, 0);
 
+  // ASM_INPUT_P - This flag is set if this is a non-extended ASM, which means
+  // that the asm string should not be interpreted, other than to escape $'s.
+  if (ASM_INPUT_P(exp)) {
+    const char *InStr = TREE_STRING_POINTER(str);
+    std::string Result;
+    while (1) {
+      switch (*InStr++) {
+      case 0: return Result;                 // End of string.
+      default: Result += InStr[-1]; break;   // Normal character.
+      case '$': Result += "$$"; break;       // Escape '$' characters.
+      }
+    }
+  }
+  
   // Expand [name] symbolic operand names.
   str = resolve_asm_operand_names(str, ASM_OUTPUTS(exp), ASM_INPUTS(exp));
 
-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 Sep 28 14:31:59 2006
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Sep 2006 14:31:59 -0500
Subject: [LLVMbugs] [Bug 902] asmparser crash on invalid
Message-ID: <200609281931.k8SJVxnw015062@zion.cs.uiuc.edu>

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

rspencer at x10sys.com changed:

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



------- Additional Comments From rspencer at x10sys.com  2006-09-28 14:31 -------
Fixed with this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060925/038179.html

Errors are generated with the YYERROR macro which can only be called from
a production (inside yyparse) because of the goto statement in the macro.
This lead to several situations where GEN_ERROR was not called but
GenerateError was used instead (because it doesn't use YYERROR). However,
in such situations, catching the error much later (e.g. at the end of
the production) is not sufficient because LLVM can assert on invalid data
before the end of the production is reached. The solution is to ensure that
the CHECK_FOR_ERROR macro (which invokes YYERROR if there's an error) is
used as soon as possible after a call to GenerateError has been made.




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