Michael Spencer | 1 Jan 02:51 2011
Picon

Re: Compilation of libc++

On Thu, Dec 30, 2010 at 8:45 PM, Maz <ma.mazmaz <at> gmail.com> wrote:
> Hi all,
> I checked out the libc++ repository and tried to build it with the ./buildit
> command. However I got the following errors: https://gist.github.com/760608
> Thanks,
> Maz

What platform are you building on?

Also, try the CMake build.

- Michael Spencer

_______________________________________________
cfe-dev mailing list
cfe-dev <at> cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Michael Spencer | 1 Jan 03:01 2011
Picon

Re: libc++ for Windows

On Fri, Dec 31, 2010 at 6:36 AM, Ruben Van Boxem
<vanboxem.ruben@...> wrote:
> Hi,
>
> I was wondering if there are plans (in the near future/today) to "port"
> libc++ to the Windows platform? This would make the project a lot more
> useful than it is right now, as clang is starting to get better at Windows
> stuff.
>
> PS: How would I go about building libc++ on Windows right now (to see if I
> can get the rough edges off before the serious work starts).
>
> Thanks!
>
> Ruben

Howard is fully welcoming patches for Windows support. I ported libc++
to CMake (already in tree) and have started working on Windows support
(not in tree). I have about %25 of it compiling, however, the changes
I made were mainly just to get it to compile (not necessarily run) so
that I could figure out what needs to be done for a proper port.

My current plan (not the official plan) for porting in general is to
design and implement a constraint based configuration language to
generate C Preprocessor code that does the actual compiler/platform
checks to present a full POSIX 2008 API for the rest of the library to
use.

- Michael Spencer
(Continue reading)

Ruben Van Boxem | 1 Jan 12:11 2011
Picon

Re: libc++ for Windows

2011/1/1 Michael Spencer <bigcheesegs@...>:
> On Fri, Dec 31, 2010 at 6:36 AM, Ruben Van Boxem
> <vanboxem.ruben@...> wrote:
>> Hi,
>>
>> I was wondering if there are plans (in the near future/today) to "port"
>> libc++ to the Windows platform? This would make the project a lot more
>> useful than it is right now, as clang is starting to get better at Windows
>> stuff.
>>
>> PS: How would I go about building libc++ on Windows right now (to see if I
>> can get the rough edges off before the serious work starts).
>>
>> Thanks!
>>
>> Ruben
>
> Howard is fully welcoming patches for Windows support. I ported libc++
> to CMake (already in tree) and have started working on Windows support
> (not in tree). I have about %25 of it compiling, however, the changes
> I made were mainly just to get it to compile (not necessarily run) so
> that I could figure out what needs to be done for a proper port.
>
> My current plan (not the official plan) for porting in general is to
> design and implement a constraint based configuration language to
> generate C Preprocessor code that does the actual compiler/platform
> checks to present a full POSIX 2008 API for the rest of the library to
> use.
>
> - Michael Spencer
(Continue reading)

陳韋任 | 1 Jan 14:15 2011
Picon

clang on FreeBSD

Hi, folks

  clang/clang++ fail to compile programs on FreeBSD 8 (amd64). Even the binary
which I downloaded from
http://llvm.org/releases/2.8/clang+llvm-2.8-freebsd8-amd64.tar.xz
failed.

  Here is the error messge,

-------------------------------------------------------------------------------
$ clang test.c
/usr/local/bin/ld: error in /usr/lib/crtend.o(.eh_frame); no .eh_frame_hdr table will be created.
-------------------------------------------------------------------------------

  Any ideas? Thanks.

Regards,
chenwj

--

-- 
Wei-Ren Chen (陳韋任)
Parallel Processing Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

_______________________________________________
cfe-dev mailing list
cfe-dev <at> cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
(Continue reading)

David Chisnall | 1 Jan 14:33 2011

Re: libc++ for Windows

On 1 Jan 2011, at 11:11, Ruben Van Boxem wrote:

> There is some work on the way to reimplement pthread API in the
> mingw-w64 runtime

I've not looked at this, but it's worth noting that supporting the pthread API on Windows is MUCH easier if
you are willing to break XP compatibility.  Microsoft introduced a new set of primitives with Vista that
mean that you no longer need the complex userspace stuff to implement the various POSIX synchronisation
primitives that weren't properly supported by Windows.  These should also be expressive enough for most
of the C++0x threading stuff if used directly, so supporting Vista+ is likely to be much easier than
supporting XP and earlier.

David

-- Sent from my PDP-11
Michael Spencer | 1 Jan 17:23 2011
Picon

Re: libc++ for Windows

On Sat, Jan 1, 2011 at 6:11 AM, Ruben Van Boxem
<vanboxem.ruben@...> wrote:
> 2011/1/1 Michael Spencer <bigcheesegs@...>:
>> On Fri, Dec 31, 2010 at 6:36 AM, Ruben Van Boxem
>> <vanboxem.ruben@...> wrote:
>>> Hi,
>>>
>>> I was wondering if there are plans (in the near future/today) to "port"
>>> libc++ to the Windows platform? This would make the project a lot more
>>> useful than it is right now, as clang is starting to get better at Windows
>>> stuff.
>>>
>>> PS: How would I go about building libc++ on Windows right now (to see if I
>>> can get the rough edges off before the serious work starts).
>>>
>>> Thanks!
>>>
>>> Ruben
>>
>> Howard is fully welcoming patches for Windows support. I ported libc++
>> to CMake (already in tree) and have started working on Windows support
>> (not in tree). I have about %25 of it compiling, however, the changes
>> I made were mainly just to get it to compile (not necessarily run) so
>> that I could figure out what needs to be done for a proper port.
>>
>> My current plan (not the official plan) for porting in general is to
>> design and implement a constraint based configuration language to
>> generate C Preprocessor code that does the actual compiler/platform
>> checks to present a full POSIX 2008 API for the rest of the library to
>> use.
(Continue reading)

Ted Kremenek | 1 Jan 23:38 2011
Picon

Re: Libclang and Objective-C headers

Header files inherently have less meaning until they are actually included.  How about create a fake t.m
that includes the header, and analyze that?

On Dec 31, 2010, at 9:47 AM, David Chisnall <csdavec@...> wrote:

> Hi,
> 
> I'm trying to use libclang to gather information about Objective-C headers.  Unfortunately, clang
appears to default to C for .h files (probably sensible) and to refer to ignore -x options passed in to
clang_createTranslationUnitFromSourceFile() and clang_parseTranslationUnit().  
> 
> Is there an existing way of overriding the default language choice when parsing headers (I assume that the
XCode people needed this for editing Objective-C headers?), and if so what is it?  
> 
> Alternatively, would it be possible for libclang to automatically detect the language of header files? 
It's relatively easy to tell C[++] and Objective-C[++] apart (spot an #import or an  <at> -keyword anywhere),
but telling C and C++ apart is probably a bit harder.
> 
> David
> 
> -- Sent from my STANTEC-ZEBRA
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@...
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Ted Kremenek | 1 Jan 23:40 2011
Picon

Re: source-code representation of an Expr

We should probably add this to a FAQ of some sort that documents how to do X with Clang.

On Dec 30, 2010, at 12:02 PM, Sam <sam-vD/9ycScLEE3uPMLIKxrzw@public.gmane.org> wrote:

John, 

That works perfectly.  Thank you so much for your help!

Sam

On Wed, Dec 29, 2010 at 4:20 PM, John McCall <rjmccall-2kanFRK1NckAvxtiuMwx3w@public.gmane.org> wrote:
On Dec 29, 2010, at 12:53 PM, Sam wrote:
> Yes, I just don't know what to *do* with it ;-) In other words, I don't see a clear use of the SourceManager API once I have the SourceRange to extract the Expr's source-code.  I don't see any API calls that use SourceRange or beginning and ending SourceLocations for source-code extraction.

We should probably make some API for this.

What you can do for now is something like the following:

 SourceRange range = expr->getSourceRange();
 if (range.getBegin().isMacroID() || range.getEnd().isMacroID()) {
   // handle this case
 } else if (!sourceManager.isFromSameFile(range.getBegin(), range.getEnd())) {
   // handle this case
 } else {
   range.setEnd(preprocessor.getLocForEndOfToken(range.getEnd()));
   const char *begin = sourceManager.getCharacterData(range.getBegin());
   const char *end = sourceManager.getCharacterData(range.getEnd());
   llvm::StringRef string(begin, end - begin);
   // now you can do whatever you want
 }

John.

_______________________________________________
cfe-dev mailing list
cfe-dev-Tmj1lob9twqVc3sceRu5cw@public.gmane.org
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
cfe-dev@...
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
David Chisnall | 1 Jan 23:44 2011
Picon

Re: Libclang and Objective-C headers

On 1 Jan 2011, at 22:38, Ted Kremenek wrote:

> Header files inherently have less meaning until they are actually included.  How about create a fake t.m
that includes the header, and analyze that?

For one thing, I want to perform syntax highlighting on the header - including it would make that vastly more
complicated because I'd have to create two translation units per header and track them independently.  

I'm not sure what you mean by 'less meaning' either.  There is no semantic difference between a header and a
one-line source file that just includes that header, as a compilation unit.  Neither C, C++, nor
Objective-C makes any differentiation between source files and header files - they're purely
programmer a convention, as is the file extension given to source files, so libclang should not really be
treating them differently.  If someone chooses to name their source files .cplusplus or .objectivec then
this should work as well, as long as a language is specified (although, going back to my original point,
libclang apparently refuses to accept -x flags, and I don't know why).

David

--
This email complies with ISO 3103
Ted Kremenek | 1 Jan 23:55 2011
Picon

Re: Fixed Point Analysis on GRExprEngine

On Dec 27, 2010, at 5:02 AM, Nimrod Partush
<nimi@...> wrote:

> 1. I've noticed that CLang has 2 different analysis modules: GRExprEngine and DataFlowSolver. The
former has advanced abstract domains but does not perform fixed point analysis (but rather bounded
checking) like the latter. I want to use GRExprEngine for fixed point analysis (i,e, i want to invoke a Join
during the analysis). How can i do that?

This would require some major surgery in the core engine.  It would also require API hooks from the various
checkers to perform the join operation.  Probably the place to handle the joins would be when worklist
units corresponding to block edges are dequeued from the worklist.

> 
> 2. What are your thoughts on linking the APRON abstract domain library to CLang? This will allow for a much
stronger constraint language than the current one.

It depends.  Performance is actually very important in the analysis engine, so depending on another
library form such core functionality would put fairly strong requirements on that other library. 
Switching over to another abstract domain library as the "default" would be a huge change, and not one
taken lightly.

One of the design points of the analysis engine was to try and allow flexible modeling depending on how much
analysis sophistication is desired.  For example, the ConstraintManager and StoreManager interfaces
are thin and virtual, allowing one to swap in entirely different constraint managers.  While the SVal
interface is still fairly immature, the hope is that it would be flexible enough that it could easily map to
other abstract domains (or possibly wrap the abstract domains of other libraries).  That way someone
could use an external constraint solver while the main analysis engine (and checkers) reason using
high-level "intentional" APIs.  I'm not familiar with APRON, but it could possible be incorporated in
this way.

Gmane