Results of the FreeBSD Ports build with CC=clang

Hello all,

Because we at FreeBSD have a source package manager called Ports with
over 20000 packages, we thought it would be nice to waste some CPU
cycles on the build cluster to see how well Clang performs.

Unfortunately it was only capable of building 7030 packages
successfully. This sounds very bad, but when you keep in mind that it
wasn't able to build libiconv (on which 9600 other ports depend directly
or indirectly, mainly because of GNU make), that's still quite
impressive.

The build cluster only attempted to build 7241 ports, of which 211
failed. The error logs can be viewed here:

	http://pointyhat.freebsd.org/errorlogs/i386-8-exp-latest/

After some filtering and sorting, I've come up with this list, where
I've categorized all error logs:

	http://80386.nl/pub/clang-portsbuild.txt

I'll discuss some of the categories here:

GNU89:
	A lot of ports currently don't build, because they depend on
	C89, or at least GCC's `-std=gnu89' semantics. Most of them have
	missing symbols, because they use GNU-style inlining, while
	Clang uses ISO C99 style inlining by default (because it uses
	-std=gnu99).

Re: Where to put exception spec source locations?

On May 31, 2009, at 11:42 AM, Sebastian Redl wrote:
> Where in the AST would be a good home for exception specification  
> source
> locations? I store the thrown types in the Type hierarchy, but I
> obviously can't do that for source locations.
>
> If it was only functions, I could put them into the FunctionDecl:
>
> void fn() throw(int);
>
> However, what about this function pointer?
>
> void (*fn)() throw(int);
>
> It only has some kind of VarDecl. It would be very weird to extend
> VarDecl with source locations for an exception spec, and it wouldn't
> work anyway:
>
> void (*fn)(void (*)() throw (int)) throw(int);
>
> What we have here is a pointer to a function that could throw int, and
> takes as its only parameter a pointer to a function that could throw
> int. One VarDecl for the whole construct, and of course I could extend
> it to as many parameters as Clang supports (2^20-1).

Given these examples, I think that the only reasonable answer is to  
put some SourceLocations into the type system.

> I need such source locations to accurately point to the types that are

Re: Results of the FreeBSD Ports build with CC=clang

On Mon, Jun 1, 2009 at 9:32 AM, Ed Schouten<ed@...> wrote:
> After some filtering and sorting, I've come up with this list, where
> I've categorized all error logs:
>
>        http://80386.nl/pub/clang-portsbuild.txt

Some of the categories seem off:

iaxmodem-1.2.0.log is actually failing because we don't implicitly
define sin/cos/etc.

cdecl-2.5.log looks like a gnu89 issue.

ipsec-tools-0.7.2.log and physfs-2.0.0.log are -Werror issues.

For libbgpdump-1.4.99.8.log, it would be more accurate to say that the
constant-folder doesn't know how to fold strlen.

"Label pointers" should really be "__label__" support.

Thanks for all the information!

-Eli

Re: Results of the FreeBSD Ports build with CC=clang

* Eli Friedman <eli.friedman@...> wrote:
> Some of the categories seem off:
> 
> iaxmodem-1.2.0.log is actually failing because we don't implicitly
> define sin/cos/etc.
> 
> cdecl-2.5.log looks like a gnu89 issue.
> 
> ipsec-tools-0.7.2.log and physfs-2.0.0.log are -Werror issues.
> 
> For libbgpdump-1.4.99.8.log, it would be more accurate to say that the
> constant-folder doesn't know how to fold strlen.
> 
> "Label pointers" should really be "__label__" support.

Yeah, I was just testing you people. Thanks! 

--

-- 
 Ed Schouten <ed@...>
 WWW: http://80386.nl/

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Re: [patch] small patch to parse "using" declaration

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Re: Results of the FreeBSD Ports build with CC=clang

On Mon, Jun 1, 2009 at 9:24 PM, Ed Schouten<ed@...> wrote:
> * Eli Friedman <eli.friedman@...> wrote:
>> Some of the categories seem off:
>>
>> iaxmodem-1.2.0.log is actually failing because we don't implicitly
>> define sin/cos/etc.
>>
>> cdecl-2.5.log looks like a gnu89 issue.
>>
>> ipsec-tools-0.7.2.log and physfs-2.0.0.log are -Werror issues.
>>
>> For libbgpdump-1.4.99.8.log, it would be more accurate to say that the
>> constant-folder doesn't know how to fold strlen.
>>
>> "Label pointers" should really be "__label__" support.
>
> Yeah, I was just testing you people. Thanks! 

Okay... so, going through the other categories:
Boehm GC: This doesn't look like a clang issue, although I could be wrong.

Nested functions: We aren't going to have these anytime soon.  We
don't have a bug on file; go ahead and file it if you feel like it,
though.

Register binding: The uses here look idiotic; I'd suggest patching the
source.  We probably will support it at some point, though.  This is
PR3933.

__label__ support: This shouldn't be too hard to fix.  This is PR3429.

alloca(): I just fixed this.

Implicit definitions of sin/cos: I just fixed this.

-Werror: The errors involving %m are PR4142.  The others look like
legitimate warnings; they're asking for it by using -Werror :)

--signed-char: The ability to use a signed character type is available
to the AST, but it isn't exposed in a way that can be easily added as
a command-line option.  I'm not entirely sure how we want to implement
this.  Please file a bug to keep track of this.

--shared: I just fixed this.

-rpath/--no-undefined: These appear to be platform-specific options;
do we have a policy about those at the moment?

-I-: We're not intending to support this; please patch the packages.

-O4: You could patch the packages, although I'm slightly hesitant to
suggest that... anyone have any better suggestions?

Constant folder doesn't support strlen(): This is kind of nasty... I'm
strongly tempted to classify it into the category of "things we will
not support".  Fixing it is really simple: change the relevant line to
'static char asn_str[sizeof("65535.65535")];'.

Variable array size in structure: We're not intending to support this;
please patch the package.

Preprocessor varargs macros without ##: I'm not sure what the issue is
here... could you reduce it and file a bug?

noreturn: I think this got fixed recently.

PR4225: I have no clue how hard this is to fix.

PR4290: Not sure how to go about fixing this; I'll discuss it in the bug.

I also tried looking at a few of the Unknown; only able to figure out one:
argp-standalone-1.3.log: Looks like a gnu89 issue, although we don't
actually support the construct in question currently.

-Eli

Re: Results of the FreeBSD Ports build with CC=clang

Hi Eli,

I still have to look at the others. Little bit busy today.

* Eli Friedman <eli.friedman@...> wrote:
> Okay... so, going through the other categories:
> Boehm GC: This doesn't look like a clang issue, although I could be wrong.

Conftest fails, because of:

/usr/local/lib/libgc.so: undefined reference to `__builtin_unwind_init'

--

-- 
 Ed Schouten <ed@...>
 WWW: http://80386.nl/

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Re: Results of the FreeBSD Ports build with CC=clang

On Tue, Jun 2, 2009 at 2:13 AM, Ed Schouten<ed@...> wrote:
> Hi Eli,
>
> I still have to look at the others. Little bit busy today.
>
> * Eli Friedman <eli.friedman@...> wrote:
>> Okay... so, going through the other categories:
>> Boehm GC: This doesn't look like a clang issue, although I could be wrong.
>
> Conftest fails, because of:
>
> /usr/local/lib/libgc.so: undefined reference to `__builtin_unwind_init'

Ah, that would be clang's fault.  Fixed in r72727/r72728; you'll have
to rebuild Boehm for it to have an effect.

-Eli

Clang & Objective-C questions

_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Re: Clang & Objective-C questions

Hi Camille,

The CGObjCRuntime class was originally designed to be reused, but has  
since grown a lot of dependencies on other bits of clang, so reusing  
it requires keeping a lot of the other clang code, including the type  
system and bits of the AST.

The code generation in Étoilé's LanguageKit is based on the first  
version of CGObjCRuntime that I wrote, and doesn't have these  
dependencies (the interface is slightly more convoluted because of  
this, but it generates the same code - I have been testing most  
changes there before submitting them to clang).  Unfortunately, it  
also doesn't have an implementation for the Apple runtimes.  You may  
find some inspiration here, however, as it is currently used to  
compile a Smalltalk dialect that is ABI-compatible with GNU Objective- 
C, as well as a dialect of JavaScript.

David

On 2 Jun 2009, at 11:52, Camille Troillard wrote:

> Hello,
>
> I am learning LLVM and would like to add JIT support to the F-Script  
> language.  F-Script is a Smalltalk like scripting language that  
> lives above the Objective-C runtime.  In F-Script everything is  
> represented as an Objective-C object.
>
> Right now, when a block is parsed, a AST representation is built and  
> then interpreted.  This results in selectors calls (by large), but  
> also classes and methods definitions.
>
> My question are:
>
> 1. Do you think it would make sense to use the clang codebase  
> (specifically Objective-C CodeGen / CGObjCRuntime) in order to  
> generate the code that will replace F-Script's interpretation?
>
> (I have asked llvmdev if it was possible to use the objc code  
> generation module in clang to emit the code, and they sent me to cfe- 
> dev.)
>
> 2. If the previous answer is yes, can you point me to some code  
> where CGObjCRuntime is used?  Or advices on how to use it?
>
> 3. If this is not a good idea, do you have a suggestion for an  
> alternative approach?
>
>
> Thanks!
>
>
> Best Regards,
> Camille
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@...
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev