On Fri, Feb 13, 2009 at 7:33 PM, Chris Lattner <[email protected]> wrote: > > On Feb 13, 2009, at 7:10 PM, Daniel Dunbar wrote: > >> Nice, very very nice. >> >> Unfortunately, this is also causing us to reject quite a few of the >> applications in the LLVM test-suite. I haven't had time to diagnose >> the exact issues, but I think we are going to need to be more >> accepting of other definitions of builtins. For example: >> -- >> char *malloc(); >> void *f0() { return malloc(4); } >> -- >> >> Can you take a look? > > It's not clear to me that we should do this. Before the patch, we would > have code that "worked with with GCC" get silently miscompiled with clang.
Well, the given snippet wouldn't actually get silently miscompiled. > Now we have code that "works fine with gcc" get "summarily rejected by > clang". This is a big step forward in some ways. Agreed! > I guess it is bad that we don't accept some programs we used to, but is this > really such a bad thing? If this just affects stuff in llvm-test, I'm > inclined to just fix the programs. If this occurs in some large C code > bases, then perhaps we should try to be more lenient. I'm just concerned about the number of such programs. It seems like there might be a good tradeoff in allowing some limited but common patterns of redefinition which are "safe", with the same diagnostic perhaps but as a warning. This would still put pressure on the user but at least allow the code to compile. This seems relatively easy for us to do, what is the downside? - Daniel > > -Chris > >> >> >> - Daniel >> >> On Fri, Feb 13, 2009 at 3:52 PM, Chris Lattner <[email protected]> wrote: >>> >>> On Feb 13, 2009, at 3:20 PM, Douglas Gregor wrote: >>> >>>> Author: dgregor >>>> Date: Fri Feb 13 17:20:09 2009 >>>> New Revision: 64504 >>>> >>>> URL: http://llvm.org/viewvc/llvm-project?rev=64504&view=rev >>>> Log: >>>> Implicitly declare certain C library functions (malloc, strcpy, >>>> memmove, >>>> etc.) when we perform name lookup on them. This ensures that we >>>> produce the correct signature for these functions, which has two >>>> practical impacts: >>> >>> Nice!! >>> >>> -Chris >>> >>> _______________________________________________ >>> cfe-commits mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
