[LLVMbugs] [Bug 4241] New: Internal compile error with alias attribute

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Fri May 22 00:05:29 PDT 2009


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

           Summary: Internal compile error with alias attribute
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Solaris
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mike.emmerik at sun.com
                CC: llvmbugs at cs.uiuc.edu, mike.emmerik at sun.com


Created an attachment (id=3011)
 --> (http://llvm.org/bugs/attachment.cgi?id=3011)
Patch that WORKS AROUND the problem; may NOT be a complete fix

llvm-backend.cpp assumes that if a function entry is renamed, then an object
with the same name already exists in the symbol table. I speculate that when
the alias attribute is used, this is not valid.

In any case, when the code below is compiled, an ICE results because
getGlobalVariable() returns NULL:

void cfi_cmdset_0001() {}
void  *cfi_cmdset_0003() __attribute__((alias("cfi_cmdset_0001")));
extern typeof(cfi_cmdset_0003) cfi_cmdset_0003;

Steps to reproduce
==================
Compile the above or attached code with
  llvm-gcc -c -o foo test.c

Actual results
==============
test.c:8: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.

Expected Results
================
Normal compilation with no error; valid foo.o produced.

Build Date and Platform
=======================
2009/May/20 on Solaris 2.11 (X86) llvm-gcc is 4.2-2.4 (gcc 4.2, llvm 2.4)

Additional platforms
====================
Also happens on llvm 2.5

Workaround
==========

The code can be fixed by the attached patch. It checks for G being null, and if
so, doesn't attempt to replace the presumed old symbol with the cast of the new
one. NOTE: this may not be a proper fix; the test should determine whether
there really has been a rename or an alias, and handle the two cases
appropriately.

      // If FnEntry got renamed, then there is already an object with this name
      // in the symbol table.  If this happens, the old one must be a forward
      // decl, just replace it with a cast of the new one.
      if (FnEntry->getName() != Name) {
        GlobalVariable *G = TheModule->getGlobalVariable(Name, true);
        assert(G && G->isDeclaration() && "A global turned into a function?");
+       if (G) {                    /* G can be NULL! */
        // Replace any uses of "G" with uses of FnEntry.
        Value *GInNewType = TheFolder->CreateBitCast(FnEntry, G->getType());
        G->replaceAllUsesWith(GInNewType);

        // Update the decl that points to G.
        changeLLVMValue(G, GInNewType);

        // Now we can give GV the proper name.
        FnEntry->takeName(G);

        // G is now dead, nuke it.
        G->eraseFromParent();          
+     } /* End if */
      }


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



More information about the llvm-bugs mailing list