[LLVMbugs] [Bug 3541] New: improve builtin function handling

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Tue Feb 10 13:36:12 PST 2009


           Summary: improve builtin function handling
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org,
                    dgregor at apple.com

The X86-64 ABI work exposed a GCC "feature" that clang isn't implementing. 
Basically, if you use "calloc" without a prototype, GCC knows that it returns a
void* and gives it the right prototype.  clang doesn't know this, and so it
defaults to returning int, which is different according to the ABI.

The proposed fix that we discussed is as follows:

1) add these builtins to the builtins.def file.
2) add a new "give me your builtin ID" method to FunctionDecl.  It would return
true if the name is an identifier, if the identifier has a builtin ID, and if
the decl context is the translation unit.  Stuff the like the printf format
checking stuff can be keyed off this instead of using strcmp of the callee
3) when handling a definition (either implicit definition or redefinition)
check to see if we're redefining a builtin.  If so, synthesize the builtin
definition first before doing decl merging.
4) If decl merging encounters an incompatibility, this should be a hard error,
not warning like GCC does.  We don't want downstream clients to have to worry
about mangled builtin decls.
5) someday long in the future, we can add support for -ffree-standing,
-fno-builtin-calloc, etc.  This would just not prepopulate the identifier info
for calloc with a builtin ID.

Configure 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