[cfe-commits] r64504 - in /cfe/trunk: include/clang/AST/ include/clang/Basic/ lib/AST/ lib/Analysis/ lib/CodeGen/ lib/Sema/ test/Analysis/ test/CodeGen/ test/Sema/

[Douglas Gregor]

On Feb 14, 2009, at 11:32 AM, Daniel Dunbar wrote:

> On Fri, Feb 13, 2009 at 7:33 PM, Chris Lattner <clattner at apple.com>  
> 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?

I don't see a downside, other than the work involved to make this  
happen.

	- Doug