[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 13, 2009, at 7:33 PM, Chris Lattner 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.  Now we have code that "works fine with gcc" get  
> "summarily rejected by clang".  This is a big step forward in some  
> ways.

Yes. It turns serious GCC-to-anyone-else portability problems into  
warnings (and then fixes the issue after complaining) or hard errors.

>
> 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.

I, too, would be inclined just to fix llvm-test. These programs are  
non-portable if they're redefining malloc and assuming a hosted  
implementation.

>  If this occurs in some large C code bases, then perhaps we should  
> try to be more lenient.


Well, it's meant that we need to implement -ffreestanding, -fno- 
builtin-malloc, etc., since I broke FreeBSD with this change. (It  
defines its own malloc) However,

	- Doug