From listrp at gmail.com  Thu Oct  1 03:37:31 2009
From: listrp at gmail.com (Robert Purves)
Date: Thu, 1 Oct 2009 21:37:31 +1300
Subject: [cfe-dev] Ungrammatical warning for CFRelease()
Message-ID: <3D0D53E7-D7A0-462F-89B5-EE93FA8CC678@gmail.com>


warning: Incorrect decrement of the reference count of an object is  
not owned at this point by the caller
   CFRelease( s );
   ^          ~

Should be:
Incorrect decrement of the reference count of an object not owned at  
this point by the caller
or:
Incorrect decrement of the reference count of an object that is not  
owned at this point by the caller

Robert P.


From luoyonggang at gmail.com  Thu Oct  1 08:36:25 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Thu, 1 Oct 2009 21:36:25 +0800
Subject: [cfe-dev] Hi, everyone, fail on building c-index-test
Message-ID: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com>

At the first glance,  it's coming with that c-index-test is just only
containing c files (without cpp(cxx,c++) files).

So cmake recognize it as pure C project,
and so it's link options that resident in link.txt is
*/usr/bin/gcc*     CMakeFiles/c-index-test.dir/c-index-test.c.o  -o
../../../../bin/c-index-test -rdynamic ../../../../lib/libCIndex.so
../../../../lib/libclangIndex.a ../../../../lib/libclangFrontend.a
../../../../lib/libclangSema.a ../../../../lib/libclangAST.a
../../../../lib/libclangLex.a ../../../../lib/libclangBasic.a
../../../../lib/libLLVMBitReader.a ../../../../lib/libLLVMMC.a
../../../../lib/libLLVMCore.a ../../../../lib/libLLVMSupport.a
../../../../lib/libLLVMSystem.a -ldl -lpthread
-Wl,-rpath,/home/dreamkxd/llvm/lib

And so, it's won't linkage with C++ library. So it's failure to compiling
the c-index-test project

Is there any solution to this problem?



-- 
        ??
?
???
Yours
   sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091001/6b58cb04/attachment.html 

From spellegrini at dps.uibk.ac.at  Thu Oct  1 09:02:13 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Thu, 01 Oct 2009 16:02:13 +0200
Subject: [cfe-dev] Constructing use-def chains
In-Reply-To: <450138DF-26E5-4FE1-9A60-BB62C6827C43@apple.com>
References: <6dcf3dab0908300846r1779c0f3v3ba3bcdbde32a77c@mail.gmail.com>
	<481F234B-0031-4EEB-8F59-ED1C39318F65@apple.com>
	<4A9D2385.8040600@dps.uibk.ac.at>
	<27836277-C68B-4CBA-BEE2-23E76E3A401A@apple.com>
	<4A9E7216.4080605@dps.uibk.ac.at>
	<5833B84A-4E6D-4424-A261-CAAAE3D777E7@apple.com>
	<4A9FC6D4.3060603@dps.uibk.ac.at> <4A9FF277.1090007@apple.com>
	<1396084E-DF95-42CA-9B68-441AA1F21F71@apple.com>
	<4AA135A1.80609@dps.uibk.ac.at>
	<9C40A355-4963-4120-8A2C-3F939AF121B3@apple.com>
	<4AA7936D.3080008@dps.uibk.ac.at>
	<0EC7D3BD-3E1A-4C2B-B12C-ED73F00E6C88@apple.com>
	<4AAFBFB7.40406@dps.uibk.ac.at>
	<450138DF-26E5-4FE1-9A60-BB62C6827C43@apple.com>
Message-ID: <4AC4B665.9030308@dps.uibk.ac.at>

Ted Kremenek wrote:
> Hi Simone,
>
> Sorry for reviewing this second set of changes so late.  Comments inline.
Hello,
as you see I am also late :), sorry but currently I am working on other 
aspects of program analysis and I have very little time to work in DefUse.

Anyway I am doing the changes you proposed:
>
> Where this is going to bite you is here:
>
>   typedef std::map<VarDecl const*, DefUseVect> DefUseChain;
>
> If you replace this with:
>
>   typedef llvm::DenseMap<VarDecl const*, DefUseVect> DefUseChain;
>
> then fundamentally things are going to break.  This because the 
> DefUseVect values, which is a typedef for std::vector<DefUseNode>, 
> will get copied and deallocated when the table resizes.  All 
> references to the DefUseVect, or the objects they contain, will 
> incorrect at this point.
>
> The solution is to use DefUseVect* instead of DefUseVect as the value 
> for DefUseChain.
I managed to get rid of the std::map in my implementation, I defined 
DefUseChain as:

typedef llvm::DenseMap<VarDecl const*, DefUseVect*> DefUseChain;

the only problem is that now in the destructor for the DefUse class I 
have to manually free the memory allocated in the heap, and that's ugly :)

I am looking forward to do something like: typedef 
llvm::DenseMap<VarDecl const*, llvm::OwningPtr<DefUseVect> > DefUseChain;
but OwiningPrt has no copy constructor and I need to do some major 
changes in the code.

Is there in LLVM something like the boost::shared_ptr?
>
> I think the approach should be to focus on a clean API.  Using 
> templates should be avoided unless there is a huge performance need; 
> the cost of virtual functions is low if the amount of work done in the 
> virtual function call outweighs the dynamic dispatch.
I still have to look into this issue!
>
>>
>> For the rest I properly formatted the code, for the test cases I have 
>> to learn how to write test cases for LLVM :)
>
> Take a look at the Clang tests in 'test/Analysis' and friends.  
> Basically we'll need to wire up a driver option to clang-cc, and 
> you'll want to run clang-cc on some code that outputs some diagnostics 
> relevant to def-use analysis.
>
I will
> More specific comments inline.
>
>> //===------------------------- Typedefs -------------------------===//
>> class DefUseBlock;
>> class VarDeclMap;
>> typedef std::vector<DefUseBlock> DefUseData;
>> typedef llvm::DenseMap<Stmt const*, unsigned> VarRefBlockMap;
>> typedef std::vector<DefUseNode> DefUseVect;
>> typedef std::vector<DefUseNode const*> VarRefsVect;
>
> Something looks potentially wrong here.  DefUseVect is a vector of 
> DefUseNode objects, not DefUseNode*.  If the vector ever needs to be 
> resized, then the DefUseNode objects will be obliterated, and any 
> references to them (which may be in VarRefVect) will suddenly become 
> invalid.  DefUseNode is a lightweight object that you can certainly 
> keep in a vector, but if you need these objects to have stable pointer 
> addresses you will need to manually allocate them and store 
> DefUseNode* instead DefUseVect instead.  If you are concerned with 
> 'malloc()' being too slow, you can use the BumpPtrAllocator in llvm to 
> quickly allocate objects.
You are completely write, that's a potential huge problem.

I get rid of the DefUseVect so not I keep only vector to pointers. This 
also allow me to do some simplifications inside the defs_iterator and 
uses_iterator
of course there is always the issue that I need to clean the memory when 
the DefUse object is deleted.

> Again, this is really great you're interested in contributing this 
> back, and I look forward to hearing your reply.
>
> Best,
> Ted
I will continue this work this week and probably at the beginning of the 
next week I will send you the code for another iteration.

There are several things I want to improve simplifying the overall 
implementation.

Thanks again for you style lessons, and see you in few days!
bye



From kremenek at apple.com  Thu Oct  1 12:32:31 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Thu, 1 Oct 2009 10:32:31 -0700
Subject: [cfe-dev] Ungrammatical warning for CFRelease()
In-Reply-To: <3D0D53E7-D7A0-462F-89B5-EE93FA8CC678@gmail.com>
References: <3D0D53E7-D7A0-462F-89B5-EE93FA8CC678@gmail.com>
Message-ID: <896C4D4C-D721-4ADA-A7D2-E3470FE50E19@apple.com>

Fixed:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090928/021960.html

Thanks Robert!

On Oct 1, 2009, at 1:37 AM, Robert Purves wrote:

>
> warning: Incorrect decrement of the reference count of an object is
> not owned at this point by the caller
>   CFRelease( s );
>   ^          ~
>
> Should be:
> Incorrect decrement of the reference count of an object not owned at
> this point by the caller
> or:
> Incorrect decrement of the reference count of an object that is not
> owned at this point by the caller
>
> Robert P.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From dgregor at apple.com  Thu Oct  1 12:50:34 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 1 Oct 2009 10:50:34 -0700
Subject: [cfe-dev] Hi, everyone, fail on building c-index-test
In-Reply-To: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com>
References: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com>
Message-ID: <F7F01E8C-CB7D-46D9-B24B-5975AB0C5181@apple.com>


On Oct 1, 2009, at 6:36 AM, ???(Yonggang Luo) wrote:

> At the first glance,  it's coming with that c-index-test is just  
> only containing c files (without cpp(cxx,c++) files).
>
> So cmake recognize it as pure C project,
> and so it's link options that resident in link.txt is
> /usr/bin/gcc     CMakeFiles/c-index-test.dir/c-index-test.c.o  - 
> o ../../../../bin/c-index-test -rdynamic ../../../../lib/ 
> libCIndex.so ../../../../lib/libclangIndex.a ../../../../lib/ 
> libclangFrontend.a ../../../../lib/libclangSema.a ../../../../lib/ 
> libclangAST.a ../../../../lib/libclangLex.a ../../../../lib/ 
> libclangBasic.a ../../../../lib/libLLVMBitReader.a ../../../../lib/ 
> libLLVMMC.a ../../../../lib/libLLVMCore.a ../../../../lib/ 
> libLLVMSupport.a ../../../../lib/libLLVMSystem.a -ldl -lpthread -Wl,- 
> rpath,/home/dreamkxd/llvm/lib
>
> And so, it's won't linkage with C++ library. So it's failure to  
> compiling the c-index-test project
>
> Is there any solution to this problem?

You're building using CMake? Try modifying tools/CIndex/CMakeLists.txt  
by adding the following command at the end:

   set_target_properties(CIndex
     PROPERTIES
     LINKER_LANGUAGE CXX)

If that works for you, please tell me so I can commit the change to svn.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091001/163b39b9/attachment.html 

From raila at illinois.edu  Thu Oct  1 15:24:35 2009
From: raila at illinois.edu (david raila)
Date: Thu, 1 Oct 2009 15:24:35 -0500
Subject: [cfe-dev] implementing language extensions in clang
Message-ID: <4AC51003.7060309@illinois.edu>


     I am adding extensions to clang for annotating c++ and doing some 
static analysis and checking.
Need at least one new type, annotations (after) declarations and methods 
to start.
Are there some guidelines and/or can someone give some advice?
The plan is currently:
  1. Mod clang to digest the syntax and ignore the extensions.
  2. Add static analysis and type checking w.r.t. the new constructs and 
attributes.
Thanks,
dkr


From mortay at apple.com  Thu Oct  1 17:13:16 2009
From: mortay at apple.com (Craig Mortensen)
Date: Thu, 1 Oct 2009 15:13:16 -0700
Subject: [cfe-dev] XML AST dump: Obj-C class,
	method and informal_protocol missing
Message-ID: <A5E7E997-C98C-4C83-9C05-B71CFFA593D0@apple.com>

Hello,

When using clang-cc to output the AST tree for a given objective-c  
header, an xml file was produced without the objective-c class,  
methods or informal protocol declarations.

How can this information be included?  I'm using the "-x=objective-c"  
option and it does parse the objective-c header OK.

I'm using this command:
/Developer/usr/libexec/clang-cc -ast-print-xml --mcpu=yonah -v  -o / 
tmp/outputCraig.xml -x=objective-c Craig.h

Note: Craig.h is attached to this email.

Thank you,

Craig


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Craig.h
Type: application/octet-stream
Size: 166 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091001/52ee467d/attachment.obj 

From dgregor at apple.com  Thu Oct  1 17:40:42 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 1 Oct 2009 15:40:42 -0700
Subject: [cfe-dev] XML AST dump: Obj-C class,
	method and informal_protocol missing
In-Reply-To: <A5E7E997-C98C-4C83-9C05-B71CFFA593D0@apple.com>
References: <A5E7E997-C98C-4C83-9C05-B71CFFA593D0@apple.com>
Message-ID: <5F01D055-C009-4CBA-9F26-58C2868BE7EA@apple.com>


On Oct 1, 2009, at 3:13 PM, Craig Mortensen wrote:
> When using clang-cc to output the AST tree for a given objective-c  
> header, an xml file was produced without the objective-c class,  
> methods or informal protocol declarations.
>
> How can this information be included?  I'm using the "-x=objective- 
> c" option and it does parse the objective-c header OK.
>
> I'm using this command:
> /Developer/usr/libexec/clang-cc -ast-print-xml --mcpu=yonah -v  -o / 
> tmp/outputCraig.xml -x=objective-c Craig.h

The XML dump doesn't cover all of the Clang AST, and has no support  
for Objective-C. You could add the appropriate definitions into  
include/clang/Frontend/DeclXML.def to get XML output for Objective-C  
declarations.

	- Doug

From john.thompson.jtsoftware at gmail.com  Thu Oct  1 18:34:11 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 1 Oct 2009 16:34:11 -0700
Subject: [cfe-dev] Complex literals and VS mode?
Message-ID: <aad8390910011634o289790b6gca34995be3acf5f0@mail.gmail.com>

Three tests are failing on Windows because complex literals (suffix 'i')
appear not to be supported when the Microsoft emulation option is on (which
it is by default for the Visual Studio-built version).  I don't know
anything about complex literals in general, or if this was intentional, or
whether it is supported in VC++, but the enclosed patch makes the following
tests pass:

mandel.c
complex-int.c
exprs.c

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091001/592cc555/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imaginaryliterals.patch
Type: application/octet-stream
Size: 1005 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091001/592cc555/attachment.obj 

From john.thompson.jtsoftware at gmail.com  Thu Oct  1 18:41:22 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 1 Oct 2009 16:41:22 -0700
Subject: [cfe-dev] Complex literals and VS mode?
In-Reply-To: <aad8390910011634o289790b6gca34995be3acf5f0@mail.gmail.com>
References: <aad8390910011634o289790b6gca34995be3acf5f0@mail.gmail.com>
Message-ID: <aad8390910011641y519fd0f5t369f25af5fa7060e@mail.gmail.com>

Wait, this patch has problems, not accounting for the s increment, but if
someone will let me know if it should work, I'll fix it.

On Thu, Oct 1, 2009 at 4:34 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Three tests are failing on Windows because complex literals (suffix 'i')
> appear not to be supported when the Microsoft emulation option is on (which
> it is by default for the Visual Studio-built version).  I don't know
> anything about complex literals in general, or if this was intentional, or
> whether it is supported in VC++, but the enclosed patch makes the following
> tests pass:
>
> mandel.c
> complex-int.c
> exprs.c
>
> -John
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091001/468b06ad/attachment.html 

From luoyonggang at gmail.com  Fri Oct  2 22:06:02 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sat, 3 Oct 2009 11:06:02 +0800
Subject: [cfe-dev] Hi, everyone, fail on building c-index-test
In-Reply-To: <806065d90910011611t3e611195u43454c6e436940e4@mail.gmail.com>
References: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com> 
	<F7F01E8C-CB7D-46D9-B24B-5975AB0C5181@apple.com>
	<806065d90910011611t3e611195u43454c6e436940e4@mail.gmail.com>
Message-ID: <806065d90910022006s2e2fd2b0tc0600221bdee6695@mail.gmail.com>

>
> Yes, but I does't modify the file  tools/CIndex/CMakeLists.txt.And I
> modify another file AddLLVM.cmake
>
> And I think it's get more meaning, because llvm is C++ application, so it's
> must be using the std-c++ library(stl)
> So need to linkage with C++,
> By the way, I've already test, it's working:)
>
At last, I get it working, And I refactoring the llvm cmake system.

I think did this should make cmake for more easy to diagnose, because we
always facing all kinds of linking error around the development period, for
the
reason of fast locate the error, i print out the link info(). Because of gcc
is very dependent on the order of the library to linked,
So I changed the order for the link of dynamic library, also I removed the
redundant function in LLVMConfig.cmake module

By the way, for the last success on building CIndex, we must apply these two
patch *simultaneous* .
And I want to mention, if LLVM will support dynamic library linkage?
If that's true, then we can modify the cmake system to support it:)
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091003/d0b4ad12/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-cmake-message-dependent.patch
Type: application/octet-stream
Size: 2743 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091003/d0b4ad12/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang-cmake-fix-CIndex-link-error-mingw.patch
Type: application/octet-stream
Size: 853 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091003/d0b4ad12/attachment-0001.obj 

From mark at mirell.org  Fri Oct  2 22:14:11 2009
From: mark at mirell.org (Mark A. Miller)
Date: Fri, 2 Oct 2009 22:14:11 -0500
Subject: [cfe-dev] Cross-compiling with clang
Message-ID: <31014a580910022014p7dda3b8eyf80b051468fea77c@mail.gmail.com>

As a preface, I am not a compiler developer, so please take my questions
with a grain of salt. But there doesn't appear to be a clang-user mailing
list, so I'm posting to -dev.

I'm extremely interested in clang, since it both attempts to be saner than
what gcc has become, and doesn't have the community forking licensing issues
of GPLv2 and GPLv3. My recent projects have involved building
cross-compilers for various targets, such as ARM, MIPS, PPC, sh4, et cetera.

My main question is, has any work been done on allowing clang to
cross-compile various targets? I found the following bug:
http://llvm.org/bugs/show_bug.cgi?id=4127 which indicated that it was still
a work in progress.

Also, I suppose this question may be better posed to the llvm list, but is
there any documentation on how to use a gcc frontend and llvm backend to
cross-compile?

Lastly, and this is more of a slight nitpick issue, since I managed to find
the bug with the following mailing list post:
http://article.gmane.org/gmane.comp.compilers.clang.devel/5893 I'd point out
that the -arch feature currently only works on MacOSX. I wasted several
hours trying to figure out what I was doing wrong on my Linux installation
until I found ths out.

Thanks!

-- 
Mark A. Miller
mark at mirell.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091002/fe90d1c0/attachment.html 

From clattner at apple.com  Sat Oct  3 01:28:39 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 2 Oct 2009 23:28:39 -0700
Subject: [cfe-dev] Cross-compiling with clang
In-Reply-To: <31014a580910022014p7dda3b8eyf80b051468fea77c@mail.gmail.com>
References: <31014a580910022014p7dda3b8eyf80b051468fea77c@mail.gmail.com>
Message-ID: <5BF49EAE-035B-48D6-9488-F71981D09477@apple.com>

On Oct 2, 2009, at 8:14 PM, Mark A. Miller wrote:
> As a preface, I am not a compiler developer, so please take my  
> questions with a grain of salt. But there doesn't appear to be a  
> clang-user mailing list, so I'm posting to -dev.
>
> I'm extremely interested in clang, since it both attempts to be  
> saner than what gcc has become, and doesn't have the community  
> forking licensing issues of GPLv2 and GPLv3. My recent projects have  
> involved building cross-compilers for various targets, such as ARM,  
> MIPS, PPC, sh4, et cetera.
>
> My main question is, has any work been done on allowing clang to  
> cross-compile various targets? I found the following bug: http://llvm.org/bugs/show_bug.cgi?id=4127 
>  which indicated that it was still a work in progress.
>
> Also, I suppose this question may be better posed to the llvm list,  
> but is there any documentation on how to use a gcc frontend and llvm  
> backend to cross-compile?
>
> Lastly, and this is more of a slight nitpick issue, since I managed  
> to find the bug with the following mailing list post: http://article.gmane.org/gmane.comp.compilers.clang.devel/5893 
>  I'd point out that the -arch feature currently only works on  
> MacOSX. I wasted several hours trying to figure out what I was doing  
> wrong on my Linux installation until I found ths out.

Hi Mark,

This is an area that we are actively interested in involving, but no  
one is driving yet.  Are you interested in helping out?  I'm not too  
familiar with the issues and Daniel (who is most knowledgeable about  
the driver) is out on vacation for 2 weeks.

-Chris 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091002/71da1d5a/attachment.html 

From ladybhaal at gmail.com  Sat Oct  3 04:43:58 2009
From: ladybhaal at gmail.com (Michelle Bhaal)
Date: Sat, 3 Oct 2009 19:43:58 +1000
Subject: [cfe-dev] Error compiling clang on Windows,
	DiagnosticCommonKinds.inc not found
Message-ID: <5b344ead0910030243y5df1aad5q7eda240e788cb039@mail.gmail.com>

I have downloaded clang (83246) and llvm (83257) via subversion.  I
used cmake 2.8 beta to create a solution file for Visual Studio 2010
beta and attempted to compile clang-cc but I repeatedly get the
following error:

fatal error C1083: Cannot open include file:
'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory

I have confirmed that this file does not exist.
DiagnosticCommonKinds.inc.rule and DiagnosticCommonKinds.tds do exist
however.

I am running Windows 7 RC

What am I doing wrong?  What have I missed?

Michelle

From luoyonggang at gmail.com  Sat Oct  3 05:35:49 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sat, 3 Oct 2009 18:35:49 +0800
Subject: [cfe-dev] Error compiling clang on Windows,
	DiagnosticCommonKinds.inc 	not found
In-Reply-To: <5b344ead0910030243y5df1aad5q7eda240e788cb039@mail.gmail.com>
References: <5b344ead0910030243y5df1aad5q7eda240e788cb039@mail.gmail.com>
Message-ID: <806065d90910030335g7b602a0bndaaa662d3f463b99@mail.gmail.com>

Mmmm, it's seems that because llvm and clang doesn't share the same
add_executive function, and clang's version does't process those
source files, so clang can't generate the .inc files but llvm can do
that.

2009/10/3, Michelle Bhaal <ladybhaal at gmail.com>:
> I have downloaded clang (83246) and llvm (83257) via subversion.  I
> used cmake 2.8 beta to create a solution file for Visual Studio 2010
> beta and attempted to compile clang-cc but I repeatedly get the
> following error:
>
> fatal error C1083: Cannot open include file:
> 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
>
> I have confirmed that this file does not exist.
> DiagnosticCommonKinds.inc.rule and DiagnosticCommonKinds.tds do exist
> however.
>
> I am running Windows 7 RC
>
> What am I doing wrong?  What have I missed?
>
> Michelle
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From ladybhaal at gmail.com  Sat Oct  3 05:37:26 2009
From: ladybhaal at gmail.com (Michelle Bhaal)
Date: Sat, 3 Oct 2009 20:37:26 +1000
Subject: [cfe-dev] Error compiling clang on Windows,
	DiagnosticCommonKinds.inc 	not found
In-Reply-To: <806065d90910030335g7b602a0bndaaa662d3f463b99@mail.gmail.com>
References: <5b344ead0910030243y5df1aad5q7eda240e788cb039@mail.gmail.com>
	<806065d90910030335g7b602a0bndaaa662d3f463b99@mail.gmail.com>
Message-ID: <5b344ead0910030337i2646f288nd0a2e489d3b4b186@mail.gmail.com>

Ok, how do I fix this?

Michelle

2009/10/3 ??????(Yonggang Luo) <luoyonggang at gmail.com>:
> Mmmm, it's seems that because llvm and clang doesn't share the same
> add_executive function, and clang's version does't process those
> source files, so clang can't generate the .inc files but llvm can do
> that.
>
> 2009/10/3, Michelle Bhaal <ladybhaal at gmail.com>:
>> I have downloaded clang (83246) and llvm (83257) via subversion.  I
>> used cmake 2.8 beta to create a solution file for Visual Studio 2010
>> beta and attempted to compile clang-cc but I repeatedly get the
>> following error:
>>
>> fatal error C1083: Cannot open include file:
>> 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
>>
>> I have confirmed that this file does not exist.
>> DiagnosticCommonKinds.inc.rule and DiagnosticCommonKinds.tds do exist
>> however.
>>
>> I am running Windows 7 RC
>>
>> What am I doing wrong?  What have I missed?
>>
>> Michelle
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
> --
> ??????????????????
>
>         ????
> ??
> ??????
> Yours
>    sincerely,
> Yonggang Luo
>


From clattner at apple.com  Sat Oct  3 15:26:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 3 Oct 2009 13:26:16 -0700
Subject: [cfe-dev] implementing language extensions in clang
In-Reply-To: <4AC51003.7060309@illinois.edu>
References: <4AC51003.7060309@illinois.edu>
Message-ID: <80AC1C97-DF25-4D41-B857-E6BD869094F5@apple.com>


On Oct 1, 2009, at 1:24 PM, david raila wrote:

>
>     I am adding extensions to clang for annotating c++ and doing some
> static analysis and checking.
> Need at least one new type, annotations (after) declarations and  
> methods
> to start.
> Are there some guidelines and/or can someone give some advice?
> The plan is currently:
>  1. Mod clang to digest the syntax and ignore the extensions.
>  2. Add static analysis and type checking w.r.t. the new constructs  
> and
> attributes.

Hi David,

The best way to get started is to look for similar examples and see  
how they work.  Your plan seems pretty reasonable to me!

-Chris

From ob at bitmover.com  Sun Oct  4 20:04:23 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Sun, 4 Oct 2009 18:04:23 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
Message-ID: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>

Hi,

So I'm trying to get my feet wet with clang, and I noticed that right  
now clang doesn't notice when you declare a variable but don't use it.  
I wrote this simple testcase and put it in

llvm/tools/clang/test/Sema/warning-unused-variables.c

---
// RUN: clang -fsyntax-only -Wunused-variables -verify %s

void f0(void) {
	int	a, b; // expected-warning{{unused-variable}}
	a = 10;
	return;
}
---

And sure enough:

$ clang-cc -Wunused-variables -fsyntax-only -verify warn-unused- 
variables.c
Warnings expected but not seen:
   Line 4: unused-variable
Warnings seen but not expected:
   Line 0: unknown warning option '-Wunused-variables'

Obviously there is no -Wunused-variables flag or unused variables  
warning yet because that's what I need to implement. So my question  
is, what's the best way start hacking on this? Is there a document  
that describes the AST and where the warnings are generated? What  
files should I start reading?

Thanks,

-Oscar


From dchapiesky at yahoo.com  Mon Oct  5 08:41:28 2009
From: dchapiesky at yahoo.com (dan chap)
Date: Mon, 5 Oct 2009 06:41:28 -0700 (PDT)
Subject: [cfe-dev] Indexer Library and type references....
In-Reply-To: <A827807F-F33C-4CDB-A8A1-E0039B1F0278@gmail.com>
Message-ID: <220503.57858.qm@web112507.mail.gq1.yahoo.com>



--- On Tue, 9/29/09, Argyris Kyrtzidis <akyrtzi at gmail.com> wrote:


Type references in declarations are now tracked by the Indexer library.Note, though, that type references in expressions are not tracked because type source information for exprs (like sizeof/alignof) is not preserved in the AST yet.
I'd appreciate any feedback that you may have!
-Argiris
Argiris, 

Yay! That is great news! I will get the latest svn today...

Still, for my purposes, _every_ reference needs to be preserved.?? In order to do massive refactoring of the original source code such as shifting namespaces left or right, even the sizeof() would be needed.....?? I will give some better feedback next week.? 

In the mean time, could not a sizeof() be treated like a cast in the AST?

Daniel




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/1769dfb7/attachment.html 

From dgregor at apple.com  Mon Oct  5 09:54:06 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 5 Oct 2009 07:54:06 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
Message-ID: <CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>

Hello Oscar,

On Oct 4, 2009, at 6:04 PM, Oscar Bonilla wrote:
> So I'm trying to get my feet wet with clang, and I noticed that right
> now clang doesn't notice when you declare a variable but don't use it.

Correct, Clang is missing this warning. It would make a great addition!

> I wrote this simple testcase and put it in
>
> llvm/tools/clang/test/Sema/warning-unused-variables.c
>
> ---
> // RUN: clang -fsyntax-only -Wunused-variables -verify %s
>
> void f0(void) {
> 	int	a, b; // expected-warning{{unused-variable}}
> 	a = 10;
> 	return;
> }
> ---
>
> And sure enough:
>
> $ clang-cc -Wunused-variables -fsyntax-only -verify warn-unused-
> variables.c
> Warnings expected but not seen:
>   Line 4: unused-variable
> Warnings seen but not expected:
>   Line 0: unknown warning option '-Wunused-variables'
>
> Obviously there is no -Wunused-variables flag or unused variables
> warning yet because that's what I need to implement. So my question
> is, what's the best way start hacking on this? Is there a document
> that describes the AST and where the warnings are generated? What
> files should I start reading?

Generally, the best way to figure out how to add a new warning like  
this is to find a similar warning. Clang has -Wunused-parameter  
already implemented, so that's a great start. There are a few places  
you'll need to look at and (in some cases) modify to implement - 
Wunused-variables:

	include/clang/Basic/DiagnosticSemaKinds.td: define a new  
warn_unused_variable warning here
	lib/Sema/Sema.h: DiagnoseUnusedParameters shows how to emit a similar  
warning
	lib/Sema/SemaDecl.cpp: Sema::ActOnPopScope is where you probably want  
to look for unused variables (when they are being popped out of scope)
    	lib/Sema/SemaExpr.cpp: Sema::MarkDeclarationReferenced is called  
whenever any declaration (variable, function, method, etc.) is used by  
the source code.

Most of the documentation for the ASTs is within the AST headers,  
which is also accessible via Doxygen:

	http://clang.llvm.org/doxygen/

	- Doug

From abramobagnara at tin.it  Mon Oct  5 09:54:08 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Mon, 05 Oct 2009 16:54:08 +0200
Subject: [cfe-dev] Generation of CallExpr to builtin function
Message-ID: <4ACA0890.1020903@tin.it>


In our application we need to generate a new CallExpr to a builtin
function, but we are unable to find a way to do that.

In SemaDecl.cpp we have found

/// LazilyCreateBuiltin - The specified Builtin-ID was first used at
/// file scope.  lazily create a decl for it. ForRedeclaration is true
/// if we're creating this built-in in anticipation of redeclaring the
/// built-in.
NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II, unsigned bid,
                                     Scope *S, bool ForRedeclaration,
                                     SourceLocation Loc);

but it's inaccessible (and does also other things).

What's the right way to do that?


From john.thompson.jtsoftware at gmail.com  Mon Oct  5 10:12:42 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Mon, 5 Oct 2009 08:12:42 -0700
Subject: [cfe-dev] WIn32 test patches revisited
Message-ID: <aad8390910050812i56b87634xddf65c370f94f9d@mail.gmail.com>

Affer updating, my const-init.c fixes conflicted.  However, the new version
doesn't have the floating point fixes I put in.  The VC++ *printf routines
apparently put in an extra digit in the exponent part of a floating point
number.  The enclosed patch adds these, though perhaps I didn't pick the
most ideal regular expression...

The enclosed patch also makes imaginary literals compile, with hopefully a
correct fix for LiteralSupport.cpp this time.  The question still remains,
however.  If VC++ doesn't support something (like imaginary literals), in
Clang's Microsoft emulation mode, should Clang still support it?  Either
way, a change is needed to make the three tests using imaginary literals
pass.
 -John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/4c923860/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JT_2009_10_5.patch
Type: application/octet-stream
Size: 3605 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/4c923860/attachment.obj 

From herrold at owlriver.com  Mon Oct  5 11:18:16 2009
From: herrold at owlriver.com (R P Herrold)
Date: Mon, 5 Oct 2009 12:18:16 -0400 (EDT)
Subject: [cfe-dev] doco build issue (how to skip question)
Message-ID: <alpine.LRH.2.00.0910051200480.18212@arj.bjyevire.pbz>


from a llvm and clang CO, I am consistently getting a 
build failure down in the build of Ocaml doco

lvm[1]: Building ocamldoc documentation
make[2]: Entering directory
 	`/home/herrold/rpmbuild/BUILD/clang-20091005/bindings/ocaml'
make[3]: Entering directory
 	`/home/herrold/rpmbuild/BUILD/clang-20091005/bindings/ocaml/llvm'
llvm[3]: Documenting llvm.odoc
make[3]: I: Command not found
make[3]:
 	[/home/herrold/rpmbuild/BUILD/clang-20091005/bindings/ocaml/llvm/Debug/llvm.odoc] 
Error 127 (ignored)
make[3]: Leaving directory 
`/home/herrold/rpmbuild/BUILD/clang-20091005/bindings/ocaml/llvm'

Under the time honored principle of solving doco building 
problems last, I thought:  Hmmm --- add a ./configure option 
and skip this for the moment

But running ./configure --help, nothing jumps out an bites me 
as a proper 'disable' clause to use.  ditto reading README.txt 
and INSTALL.txt.  I see the mention of missing -I paths in 
NOTES.txt, but this seems unlikely, except for the strange 
missing 'I' Command, rather than '-I' error

CentOS 5, currently updated and a rich build environment 
platform, on a x86_64

My build passes are laborious (working towoard auto-packagin 
the SRPM and binary RPMs) -- running over an hour, and so I'd 
appreciate a pointer.

Any thought?

-- Russ herrold

From ob at bitmover.com  Mon Oct  5 12:57:19 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Mon, 5 Oct 2009 10:57:19 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
Message-ID: <9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>

On Oct 5, 2009, at 7:54 AM, Douglas Gregor wrote:

> Generally, the best way to figure out how to add a new warning like  
> this is to find a similar warning. Clang has -Wunused-parameter  
> already implemented, so that's a great start. There are a few places  
> you'll need to look at and (in some cases) modify to implement - 
> Wunused-variables:
>
> 	include/clang/Basic/DiagnosticSemaKinds.td: define a new  
> warn_unused_variable warning here
> 	lib/Sema/Sema.h: DiagnoseUnusedParameters shows how to emit a  
> similar warning
> 	lib/Sema/SemaDecl.cpp: Sema::ActOnPopScope is where you probably  
> want to look for unused variables (when they are being popped out of  
> scope)
>   	lib/Sema/SemaExpr.cpp: Sema::MarkDeclarationReferenced is called  
> whenever any declaration (variable, function, method, etc.) is used  
> by the source code.
>
> Most of the documentation for the ASTs is within the AST headers,  
> which is also accessible via Doxygen:
>
> 	http://clang.llvm.org/doxygen/
>
> 	- Doug

Okay, this seems to do it:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ob.patch
Type: application/octet-stream
Size: 1108 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/ec4ca4b4/attachment.obj 
-------------- next part --------------


and here's the testcase (I put it in test/Sema/warn-unused-variables.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: warn-unused-variables.c
Type: application/octet-stream
Size: 152 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/ec4ca4b4/attachment-0001.obj 
-------------- next part --------------


Let me know if I did it right ;)

Cheers,

-Oscar


From ob at bitmover.com  Mon Oct  5 13:17:50 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Mon, 5 Oct 2009 11:17:50 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
Message-ID: <E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>

FWIW, I found an open bug

http://llvm.org/bugs/show_bug.cgi?id=4563

so I added the patch there as well.

Cheers,

-Oscar


From herrold at owlriver.com  Mon Oct  5 15:24:01 2009
From: herrold at owlriver.com (R P Herrold)
Date: Mon, 5 Oct 2009 16:24:01 -0400 (EDT)
Subject: [cfe-dev] more doc building woes
Message-ID: <alpine.LRH.2.00.0910051622480.19978@arj.bjyevire.pbz>


I now get this:

  ...
Parsing file 
/home/herrold/rpmbuild/BUILD/clang-20091005/lib/Target/CellSPU/SPUGenCodeEmitter.inc...
Reading 
/home/herrold/rpmbuild/BUILD/clang-20091005/lib/Target/CellSPU/SPUGenDAGISel.inc...
input buffer overflow, can't enlarge buffer because scanner 
uses REJECT
make[1]: *** [regendoc] Error 2
make[1]: Leaving directory 
`/home/herrold/rpmbuild/BUILD/clang-20091005/docs'
make: *** [install] Error 1

I'll sub this arch out, and try again

-- Russ herrold

From ob at bitmover.com  Mon Oct  5 15:37:15 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Mon, 5 Oct 2009 13:37:15 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
Message-ID: <A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>

Hm, after playing with my patch a little I see it's not quite right.

struct s1 {
	unsigned int i;
};

will produce an "unused variable 'i'" warning. This is a better patch.

(I'm also adding it to the bug-tracker)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ob.patch
Type: application/octet-stream
Size: 1151 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/1f07c3cd/attachment.obj 
-------------- next part --------------


With a better testcase

-------------- next part --------------
A non-text attachment was scrubbed...
Name: warn-unused-variables.c
Type: application/octet-stream
Size: 211 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/1f07c3cd/attachment-0001.obj 
-------------- next part --------------


Cheers,

-Oscar

From dgregor at apple.com  Mon Oct  5 16:00:52 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 5 Oct 2009 14:00:52 -0700
Subject: [cfe-dev] Generation of CallExpr to builtin function
In-Reply-To: <4ACA0890.1020903@tin.it>
References: <4ACA0890.1020903@tin.it>
Message-ID: <91B635AC-C90A-44AE-B711-1E78496AE967@apple.com>


On Oct 5, 2009, at 7:54 AM, Abramo Bagnara wrote:

>
> In our application we need to generate a new CallExpr to a builtin
> function, but we are unable to find a way to do that.
>
> In SemaDecl.cpp we have found
>
> /// LazilyCreateBuiltin - The specified Builtin-ID was first used at
> /// file scope.  lazily create a decl for it. ForRedeclaration is true
> /// if we're creating this built-in in anticipation of redeclaring the
> /// built-in.
> NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II, unsigned bid,
>                                     Scope *S, bool ForRedeclaration,
>                                     SourceLocation Loc);
>
> but it's inaccessible (and does also other things).
>
> What's the right way to do that?

You can find the built-in function using Sema::ActOnIdentifierExpr,  
which will have the effect of implicitly declaring the builtin (or  
finding it if it already existed) and then building a DeclRefExpr that  
you can use as the callee of your call expression.

	- Doug

From clattner at apple.com  Mon Oct  5 16:11:47 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 5 Oct 2009 14:11:47 -0700
Subject: [cfe-dev] doco build issue (how to skip question)
In-Reply-To: <alpine.LRH.2.00.0910051200480.18212@arj.bjyevire.pbz>
References: <alpine.LRH.2.00.0910051200480.18212@arj.bjyevire.pbz>
Message-ID: <391BC97E-8E61-4C8C-BAC5-53C63A78F8C0@apple.com>


On Oct 5, 2009, at 9:18 AM, R P Herrold wrote:

>
> from a llvm and clang CO, I am consistently getting a
> build failure down in the build of Ocaml doco
>
> lvm[1]: Building ocamldoc documentation
> make[2]: Entering directory
> 	`/home/herrold/rpmbuild/BUILD/clang-20091005/bindings/ocaml'
> make[3]: Entering directory
> 	`/home/herrold/rpmbuild/BUILD/clang-20091005/bindings/ocaml/llvm'
> llvm[3]: Documenting llvm.odoc
> make[3]: I: Command not found
> make[3]:
> 	[/home/herrold/rpmbuild/BUILD/clang-20091005/bindings/ocaml/llvm/ 
> Debug/llvm.odoc]
> Error 127 (ignored)
> make[3]: Leaving directory
> `/home/herrold/rpmbuild/BUILD/clang-20091005/bindings/ocaml/llvm'
>
> Under the time honored principle of solving doco building
> problems last, I thought:  Hmmm --- add a ./configure option
> and skip this for the moment

Hi Russ,

It looks like the configure is detecting ocaml support and trying to  
build the bindings.  Try configuring with --enable-bindings=none.

-Chris

>
> But running ./configure --help, nothing jumps out an bites me
> as a proper 'disable' clause to use.  ditto reading README.txt
> and INSTALL.txt.  I see the mention of missing -I paths in
> NOTES.txt, but this seems unlikely, except for the strange
> missing 'I' Command, rather than '-I' error
>
> CentOS 5, currently updated and a rich build environment
> platform, on a x86_64
>
> My build passes are laborious (working towoard auto-packagin
> the SRPM and binary RPMs) -- running over an hour, and so I'd
> appreciate a pointer.
>
> Any thought?
>
> -- Russ herrold
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From clattner at apple.com  Mon Oct  5 16:16:42 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 5 Oct 2009 14:16:42 -0700
Subject: [cfe-dev] mmintrin-test.c patch
In-Reply-To: <aad8390909301154p45e4ede0u2f400c3be42aeb28@mail.gmail.com>
References: <aad8390909301154p45e4ede0u2f400c3be42aeb28@mail.gmail.com>
Message-ID: <0375271A-F8C7-41AF-AFF4-0EF147E42CEF@apple.com>


On Sep 30, 2009, at 11:54 AM, John Thompson wrote:

> I've enclosed an attempt at making the CodeGen/mmintrin-test.c file  
> generic, as it was failing on Windows because the Visual Studio  
> headers don't want to compile for other platforms (specified by the  
> triples).
>
> I also converted it to use FileCheck, but I'm not sure if doing the  
> grep with count was what is really needed.  Can you do that with  
> FileCheck?
> Also, please review my previous post concerning address-space- 
> field1.c, as I want to get down the proper way to convert to  
> FileCheck.  I'm thinking perhaps I should have limited it to just  
> looking for the addrspace(1) and addrspace(2) text, but let me know.
>

Hi John,

I just removed this test in r83325.  It doesn't appear to be actually  
testing anything.

-Chris


From lattner at apple.com  Mon Oct  5 16:37:16 2009
From: lattner at apple.com (Tanya Lattner)
Date: Mon, 5 Oct 2009 14:37:16 -0700
Subject: [cfe-dev] Parameter check question
Message-ID: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>

Hello,

I want to do a check on function parameters similar to the  
"err_arg_with_address_space" check that I added in  
ActOnParamDeclarator (r83165). However, this time, I only want to  
perform the check if the function has a specific attribute. Is  
ActOnParamDeclarator the right place? I'm not seeing a way to get the  
function attribute there. Or, any suggestion on where to add this?

Thanks,
Tanya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/47486665/attachment-0001.html 

From Fons.Rademakers at cern.ch  Mon Oct  5 16:38:07 2009
From: Fons.Rademakers at cern.ch (Fons Rademakers)
Date: Mon, 5 Oct 2009 23:38:07 +0200
Subject: [cfe-dev] ast-dump issue...
Message-ID: <4ACA673F.2050007@cern.ch>

Hi,

  using clang from the trunk of today, I get when doing:

clang-cc ll.cxx -ast-dump

an assertion failure in DeclPrinter.cpp:

typedef __int128_t __int128_t;
typedef __uint128_t __uint128_t;
struct __va_list_tag {
public:
     struct __va_list_tag;
     unsigned int gp_offset;
     unsigned int fp_offset;
     void *overflow_arg_area;
     void *reg_save_area;
     inline __va_list_tag();
     inline __va_list_tag(struct __va_list_tag const &);
     inline struct __va_list_tag &operator=(struct __va_list_tag const &);
     inline ~__va_list_tag();
};
typedef struct __va_list_tag __va_list_tag;
typedef __va_list_tag __builtin_va_list[1];
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef short __int16_t;
typedef unsigned short __uint16_t;
typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef long long __int64_t;
typedef unsigned long long __uint64_t;
typedef long __darwin_intptr_t;
typedef unsigned int __darwin_natural_t;
typedef int __darwin_ct_rune_t;
Assertion failed: (0 && "Unknown declarator!"), function GetBaseType, file 
/Users/rdm/llvm/src/tools/clang/lib/AST/DeclPrinter.cpp, line 105.
0   clang-cc          0x0000000100ccfee7 PrintStackTrace(void*) + 38
1   clang-cc          0x0000000100cd0475 SignalHandler(int) + 336
2   libSystem.B.dylib 0x00007fff882480aa _sigtramp + 26
3   libSystem.B.dylib 0x00007fff881ecb2a tiny_malloc_from_free_list + 1196
4   libSystem.B.dylib 0x00007fff882c40b4 __pthread_markcancel + 0
5   clang-cc          0x00000001003f888f GetBaseType(clang::QualType) + 240
6   clang-cc          0x00000001003f8d08 (anonymous 
namespace)::DeclPrinter::VisitDeclContext(clang::DeclContext*, bool) + 580
7   clang-cc          0x00000001003f9cdd (anonymous 
namespace)::DeclPrinter::VisitTranslationUnitDecl(clang::TranslationUnitDecl*) 
+ 63
8   clang-cc          0x00000001003f9e24 clang::DeclVisitor<(anonymous 
namespace)::DeclPrinter, void>::Visit(clang::Decl*) + 324
9   clang-cc          0x00000001003f88f9 
clang::Decl::print(llvm::raw_ostream&, clang::PrintingPolicy const&, 
unsigned int) const + 71
10  clang-cc          0x0000000100039b6e (anonymous 
namespace)::ASTPrinter::HandleTranslationUnit(clang::ASTContext&) + 118
11  clang-cc          0x00000001002847e0 
clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, 
clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer* 
(*)(clang::Sema&, void*), void*) + 760
12  clang-cc          0x000000010002ba21 
ProcessInputFile(clang::Preprocessor&, clang::PreprocessorFactory&, 
std::string const&, ProgActions, llvm::StringMap<bool, 
llvm::MallocAllocator> const&, llvm::LLVMContext&) + 3664
13  clang-cc          0x000000010002d137 main + 3269
14  clang-cc          0x00000001000270dc start + 52
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/libexec/clang-cc ll.cxx 
-ast-dump
1.      <eof> parser at end of file
Abort trap

Do I miss some specific additional command line options or is this a real 
issue?

The ll.cxx file is attached.

Cheers, Fons.


-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ll.cxx
Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/2eec5fb0/attachment.pl 

From dgregor at apple.com  Mon Oct  5 16:39:59 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 5 Oct 2009 14:39:59 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
	<A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
Message-ID: <6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>


On Oct 5, 2009, at 1:37 PM, Oscar Bonilla wrote:

> Hm, after playing with my patch a little I see it's not quite right.
>
> struct s1 {
> 	unsigned int i;
> };
>
> will produce an "unused variable 'i'" warning. This is a better patch.

This condition:

+    if (isa<VarDecl>(D) && !isa<ParmVarDecl>(D) &&
+	!D->isUsed() && !D->hasAttr<UnusedAttr>())
+	    Diag(D->getLocation(), diag::warn_unused_variable) << D- 
 >getDeclName();

is a good start, but I think you only want to complain about function- 
local variables, e.g., by checking that

	D->getDeclContext()->isFunctionOrMethod()

There are a few other issues that need to be resolved:

   1) If a variable is only used in an unevaluated context (such as  
the operand of a sizeof expression), it will incorrectly complain that  
the variable is unused:

void g() {
   int i;
   (void)sizeof(i);
}

   2) It incorrectly complains about variables in templates:

template<typename T> void f() {
   T t;
   t = 17;
}

With this warning, it makes sense to enable the warning when compiling  
a small-to-medium---sized C application and then look at where the  
warning triggers. Did it complain too often? Did GCC correctly  
complain about something that Clang missed?

	- Doug

From fjahanian at apple.com  Mon Oct  5 16:44:44 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Mon, 5 Oct 2009 14:44:44 -0700
Subject: [cfe-dev] ast-dump issue...
In-Reply-To: <4ACA673F.2050007@cern.ch>
References: <4ACA673F.2050007@cern.ch>
Message-ID: <C5DD9D59-2A30-4AB6-A051-3DF09CEF84A2@apple.com>

We haven't kept up with -ast-dump (or -ast-print).
Patches are welcome; or go ahead and file a bug report.

- Fariborz

On Oct 5, 2009, at 2:38 PM, Fons Rademakers wrote:

> Hi,
>
> using clang from the trunk of today, I get when doing:
>
> clang-cc ll.cxx -ast-dump
>
> an assertion failure in DeclPrinter.cpp:
>
> typedef __int128_t __int128_t;
> typedef __uint128_t __uint128_t;
> struct __va_list_tag {
> public:
>    struct __va_list_tag;
>    unsigned int gp_offset;
>    unsigned int fp_offset;
>    void *overflow_arg_area;
>    void *reg_save_area;
>    inline __va_list_tag();
>    inline __va_list_tag(struct __va_list_tag const &);
>    inline struct __va_list_tag &operator=(struct __va_list_tag const  
> &);
>    inline ~__va_list_tag();
> };
> typedef struct __va_list_tag __va_list_tag;
> typedef __va_list_tag __builtin_va_list[1];
> typedef signed char __int8_t;
> typedef unsigned char __uint8_t;
> typedef short __int16_t;
> typedef unsigned short __uint16_t;
> typedef int __int32_t;
> typedef unsigned int __uint32_t;
> typedef long long __int64_t;
> typedef unsigned long long __uint64_t;
> typedef long __darwin_intptr_t;
> typedef unsigned int __darwin_natural_t;
> typedef int __darwin_ct_rune_t;
> Assertion failed: (0 && "Unknown declarator!"), function  
> GetBaseType, file /Users/rdm/llvm/src/tools/clang/lib/AST/ 
> DeclPrinter.cpp, line 105.
> 0   clang-cc          0x0000000100ccfee7 PrintStackTrace(void*) + 38
> 1   clang-cc          0x0000000100cd0475 SignalHandler(int) + 336
> 2   libSystem.B.dylib 0x00007fff882480aa _sigtramp + 26
> 3   libSystem.B.dylib 0x00007fff881ecb2a tiny_malloc_from_free_list  
> + 1196
> 4   libSystem.B.dylib 0x00007fff882c40b4 __pthread_markcancel + 0
> 5   clang-cc          0x00000001003f888f  
> GetBaseType(clang::QualType) + 240
> 6   clang-cc          0x00000001003f8d08 (anonymous  
> namespace)::DeclPrinter::VisitDeclContext(clang::DeclContext*, bool)  
> + 580
> 7   clang-cc          0x00000001003f9cdd (anonymous  
> namespace 
> )::DeclPrinter 
> ::VisitTranslationUnitDecl(clang::TranslationUnitDecl*) + 63
> 8   clang-cc          0x00000001003f9e24  
> clang::DeclVisitor<(anonymous namespace)::DeclPrinter,  
> void>::Visit(clang::Decl*) + 324
> 9   clang-cc          0x00000001003f88f9  
> clang::Decl::print(llvm::raw_ostream&, clang::PrintingPolicy const&,  
> unsigned int) const + 71
> 10  clang-cc          0x0000000100039b6e (anonymous  
> namespace)::ASTPrinter::HandleTranslationUnit(clang::ASTContext&) +  
> 118
> 11  clang-cc          0x00000001002847e0  
> clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*,  
> clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer* (*) 
> (clang::Sema&, void*), void*) + 760
> 12  clang-cc          0x000000010002ba21  
> ProcessInputFile(clang::Preprocessor&, clang::PreprocessorFactory&,  
> std::string const&, ProgActions, llvm::StringMap<bool,  
> llvm::MallocAllocator> const&, llvm::LLVMContext&) + 3664
> 13  clang-cc          0x000000010002d137 main + 3269
> 14  clang-cc          0x00000001000270dc start + 52
> Stack dump:
> 0.      Program arguments: /Users/rdm/llvm/inst/libexec/clang-cc  
> ll.cxx -ast-dump
> 1.      <eof> parser at end of file
> Abort trap
>
> Do I miss some specific additional command line options or is this a  
> real issue?
>
> The ll.cxx file is attached.
>
> Cheers, Fons.
>
>
> -- 
> Org:    CERN, European Laboratory for Particle Physics.
> Mail:   1211 Geneve 23, Switzerland
> E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
> WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640
> #include <stdio.h>
>
> int main()
> {
>   int err = 0;
>   long l;
>   long long i, j, k;
>
>   k = 7294967295LL;
>   i = 9223372036854775807LL;
>   j = i;
>
>   printf("sizeof(int) = %lu\n", sizeof(err));
>
>   return 0;
> }
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From dgregor at apple.com  Mon Oct  5 16:58:52 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 5 Oct 2009 14:58:52 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
Message-ID: <FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>


On Oct 5, 2009, at 2:37 PM, Tanya Lattner wrote:

> Hello,
>
> I want to do a check on function parameters similar to the  
> "err_arg_with_address_space" check that I added in  
> ActOnParamDeclarator (r83165). However, this time, I only want to  
> perform the check if the function has a specific attribute. Is  
> ActOnParamDeclarator the right place? I'm not seeing a way to get  
> the function attribute there. Or, any suggestion on where to add this?


ActOnParamDeclarator won't work, since that gets can get called by the  
parser before we've seen the function attributes. I suggest putting  
this check into ActOnFunctionDeclarator (e.g., where we check for  
parameters of "void" type).

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/205036d7/attachment.html 

From dgregor at apple.com  Mon Oct  5 17:04:11 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 5 Oct 2009 15:04:11 -0700
Subject: [cfe-dev] Indexer Library and type references....
In-Reply-To: <220503.57858.qm@web112507.mail.gq1.yahoo.com>
References: <220503.57858.qm@web112507.mail.gq1.yahoo.com>
Message-ID: <1868934C-AE3A-45F0-B54F-F9D134B0C74C@apple.com>


On Oct 5, 2009, at 6:41 AM, dan chap wrote:
> --- On Tue, 9/29/09, Argyris Kyrtzidis <akyrtzi at gmail.com> wrote:
> Type references in declarations are now tracked by the Indexer  
> library.
> Note, though, that type references in expressions are not tracked  
> because type source information for exprs (like sizeof/alignof) is  
> not preserved in the AST yet.
>
> I'd appreciate any feedback that you may have!
>
> -Argiris
> Argiris,
>
> Yay! That is great news! I will get the latest svn today...
>
> Still, for my purposes, _every_ reference needs to be preserved.    
> In order to do massive refactoring of the original source code such  
> as shifting namespaces left or right,

Shifting namespaces sounds like a syntactic transformation rather than  
a transformation that needs to work on the AST.

> even the sizeof() would be needed.....   I will give some better  
> feedback next week.
>
> In the mean time, could not a sizeof() be treated like a cast in the  
> AST?

Yes, it can. For every place that a type shows up in the expression or  
statement grammar, the corresponding Expr or Stmt node will need to  
maintain type location information (probably in a TypeSpecLoc). As far  
as I can tell, all of the infrastructure is there, but someone will  
need to go through and add this information for us to maintain all  
type source information for expressions and statements.

	- Doug

From herrold at owlriver.com  Mon Oct  5 17:05:58 2009
From: herrold at owlriver.com (R P Herrold)
Date: Mon, 5 Oct 2009 18:05:58 -0400 (EDT)
Subject: [cfe-dev] doco build issue (how to skip question)
In-Reply-To: <391BC97E-8E61-4C8C-BAC5-53C63A78F8C0@apple.com>
References: <alpine.LRH.2.00.0910051200480.18212@arj.bjyevire.pbz>
	<391BC97E-8E61-4C8C-BAC5-53C63A78F8C0@apple.com>
Message-ID: <alpine.LRH.2.00.0910051802380.916@arj.bjyevire.pbz>

On Mon, 5 Oct 2009, Chris Lattner wrote:

> It looks like the configure is detecting ocaml support and trying to build 
> the bindings.  Try configuring with --enable-bindings=none.

will do -- I had tried adding, per an off list suggestiion:

 	--disable-bindings=ocaml

and that was not the incantation that worked ... configure was 
simply not happy with it.

sadly:

+ ./configure --prefix=/usr --libdir=/usr/lib64 \
         --enable-optimized --enable-debug-runtime  --enable-doxygen \
         --disable-static --with-gnu-ld  --disable-bindings=ocaml \
configure: error: invalid feature name: bindings=ocaml
error: Bad exit status from /var/tmp/rpm-tmp.46097 (%build)

Thanks

> -Chris

-- Russ herrold

From clattner at apple.com  Mon Oct  5 17:08:39 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 5 Oct 2009 15:08:39 -0700
Subject: [cfe-dev] implementing language extensions in clang
In-Reply-To: <4ACA049E.8050107@illinois.edu>
References: <4AC51003.7060309@illinois.edu>
	<80AC1C97-DF25-4D41-B857-E6BD869094F5@apple.com>
	<4ACA049E.8050107@illinois.edu>
Message-ID: <63CFFE4A-486A-4989-97E8-A5A9F8377FB4@apple.com>

<sending to cfe-dev>

On Oct 5, 2009, at 7:37 AM, david raila wrote:

> Vector extensions are reasonable?
>
> I finally stumbled on the .def files and have some region classes  
> prototyped,
> now looking for the actual tokenization of "region" in the input.

Sure, depending on what you want to add.  See also the various static  
analyzer attributes.
>
> Is there a particular development environment/tools that the  
> insiders are using?
> I'm using gdb/emacs/make which is flies reasonably straight but  
> throws me on the
> ground occasionally... :-)

I use xcode to edit, plus gdb/make.

-Chris

From dgregor at apple.com  Mon Oct  5 17:14:57 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 5 Oct 2009 15:14:57 -0700
Subject: [cfe-dev] Complex literals and VS mode?
In-Reply-To: <aad8390910011634o289790b6gca34995be3acf5f0@mail.gmail.com>
References: <aad8390910011634o289790b6gca34995be3acf5f0@mail.gmail.com>
Message-ID: <FFE0394D-42DE-4067-9026-D41ABB9445DC@apple.com>


On Oct 1, 2009, at 4:34 PM, John Thompson wrote:

> Three tests are failing on Windows because complex literals (suffix  
> 'i') appear not to be supported when the Microsoft emulation option  
> is on (which it is by default for the Visual Studio-built version).

> I don't know anything about complex literals in general, or if this  
> was intentional, or whether it is supported in VC++, but the  
> enclosed patch makes the following tests pass:

Yes, we should support complex literals even in Microsoft emulation  
mode. However, I'd really rather not have a "goto" in this code...  
could you replace that goto with some kind of "WasMicrosoftSuffix" bool?

	- Doug

From dgregor at apple.com  Mon Oct  5 17:20:17 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 5 Oct 2009 15:20:17 -0700
Subject: [cfe-dev] Error compiling clang on Windows,
	DiagnosticCommonKinds.inc not found
In-Reply-To: <5b344ead0910030243y5df1aad5q7eda240e788cb039@mail.gmail.com>
References: <5b344ead0910030243y5df1aad5q7eda240e788cb039@mail.gmail.com>
Message-ID: <5622FE6B-3BF7-40A0-83E1-53F713C11123@apple.com>


On Oct 3, 2009, at 2:43 AM, Michelle Bhaal wrote:

> I have downloaded clang (83246) and llvm (83257) via subversion.  I
> used cmake 2.8 beta to create a solution file for Visual Studio 2010
> beta and attempted to compile clang-cc but I repeatedly get the
> following error:
>
> fatal error C1083: Cannot open include file:
> 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory

What file(s) is it trying to compile when you hit this error? It's  
possible that we're missing dependencies, but I know there are at  
least a few Visual Studio users around who are able to build Clang.

	- Doug

From makslane at hotmail.com  Mon Oct  5 18:08:15 2009
From: makslane at hotmail.com (=?iso-8859-1?B?TWFrc2xhbmUgQXJh+mpvIFJvZHJpZ3Vlcw==?=)
Date: Tue, 6 Oct 2009 02:08:15 +0300
Subject: [cfe-dev] Error compiling clang on Windows,
	DiagnosticCommonKinds.inc not found
In-Reply-To: <5622FE6B-3BF7-40A0-83E1-53F713C11123@apple.com>
References: <5b344ead0910030243y5df1aad5q7eda240e788cb039@mail.gmail.com>
Message-ID: <COL106-W343A633772AA74835D7FA4DDCF0@phx.gbl>


I have this isseu before too.Make sure download the llvm and clang again with the svn (is better download all files in a empty folder)  and recreate the solution files with the cmake.
Makslane

> From: dgregor at apple.com
> Date: Mon, 5 Oct 2009 15:20:17 -0700
> To: ladybhaal at gmail.com
> CC: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] Error compiling clang on Windows,	DiagnosticCommonKinds.inc not found
> 
> 
> On Oct 3, 2009, at 2:43 AM, Michelle Bhaal wrote:
> 
> > I have downloaded clang (83246) and llvm (83257) via subversion.  I
> > used cmake 2.8 beta to create a solution file for Visual Studio 2010
> > beta and attempted to compile clang-cc but I repeatedly get the
> > following error:
> >
> > fatal error C1083: Cannot open include file:
> > 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
> 
> What file(s) is it trying to compile when you hit this error? It's  
> possible that we're missing dependencies, but I know there are at  
> least a few Visual Studio users around who are able to build Clang.
> 
> 	- Doug
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
 		 	   		  
_________________________________________________________________
Voc? sabia que o Hotmail mudou? Clique e descubra as novidades.
http://www.microsoft.com/brasil/windows/windowslive/products/hotmail.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/5e7d0ea2/attachment.html 

From Fons.Rademakers at cern.ch  Mon Oct  5 19:51:58 2009
From: Fons.Rademakers at cern.ch (Fons Rademakers)
Date: Tue, 6 Oct 2009 02:51:58 +0200
Subject: [cfe-dev] pch generation of C++ header failure...
Message-ID: <4ACA94AE.9090502@cern.ch>

Hi,

   should pch generation for a simple C++ class already work in clang 
(trunk of today)?

I try:

clang -x c++-header myclass.h

which gives an assert error:

Assertion failed: (Writer.Code != pch::STMT_NULL_PTR && "Unhandled 
expression writing PCH file"), function WriteSubStmt, file 
/Users/rdm/llvm/src/tools/clang/lib/Frontend/PCHWriterStmt.cpp, line 834.
0   clang-cc          0x0000000100ccfee7 PrintStackTrace(void*) + 38
1   clang-cc          0x0000000100cd0475 SignalHandler(int) + 336
2   libSystem.B.dylib 0x00007fff882480aa _sigtramp + 26
3   libSystem.B.dylib 0x00007fff881ecb2a tiny_malloc_from_free_list + 1196
4   libSystem.B.dylib 0x00007fff882c40b4 __pthread_markcancel + 0
5   clang-cc          0x00000001000b590c 
clang::PCHWriter::WriteSubStmt(clang::Stmt*) + 232
6   clang-cc          0x00000001000b7318 (anonymous 
namespace)::PCHStmtWriter::VisitMemberExpr(clang::MemberExpr*) + 54
7   clang-cc          0x00000001000b50f2 clang::StmtVisitor<(anonymous 
namespace)::PCHStmtWriter, void>::Visit(clang::Stmt*) + 2742
8   clang-cc          0x00000001000b58d9 
clang::PCHWriter::WriteSubStmt(clang::Stmt*) + 181
9   clang-cc          0x00000001000b6b4a (anonymous 
namespace)::PCHStmtWriter::VisitBinaryOperator(clang::BinaryOperator*) + 54
10  clang-cc          0x00000001000b6e57 clang::StmtVisitor<(anonymous 
namespace)::PCHStmtWriter, void>::VisitBinAssign(clang::BinaryOperator*) + 29
11  clang-cc          0x00000001000b48f7 clang::StmtVisitor<(anonymous 
namespace)::PCHStmtWriter, void>::Visit(clang::Stmt*) + 699
12  clang-cc          0x00000001000b58d9 
clang::PCHWriter::WriteSubStmt(clang::Stmt*) + 181
13  clang-cc          0x00000001000b82b0 (anonymous 
namespace)::PCHStmtWriter::VisitCompoundStmt(clang::CompoundStmt*) + 112
14  clang-cc          0x00000001000b4dd4 clang::StmtVisitor<(anonymous 
namespace)::PCHStmtWriter, void>::Visit(clang::Stmt*) + 1944
15  clang-cc          0x00000001000b56f3 clang::PCHWriter::FlushStmts() + 253
16  clang-cc          0x00000001000b2c86 
clang::PCHWriter::WriteDeclsBlock(clang::ASTContext&) + 846
17  clang-cc          0x00000001000a48cb 
clang::PCHWriter::WritePCH(clang::Sema&, clang::MemorizeStatCalls*, char 
const*) + 1701
18  clang-cc          0x0000000100055bee (anonymous 
namespace)::PCHGenerator::HandleTranslationUnit(clang::ASTContext&) + 256
19  clang-cc          0x00000001002847e0 
clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, 
clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer* 
(*)(clang::Sema&, void*), void*) + 760
20  clang-cc          0x000000010002ba21 
ProcessInputFile(clang::Preprocessor&, clang::PreprocessorFactory&, 
std::string const&, ProgActions, llvm::StringMap<bool, 
llvm::MallocAllocator> const&, llvm::LLVMContext&) + 3664
21  clang-cc          0x000000010002d137 main + 3269
22  clang-cc          0x00000001000270dc start + 52
23  clang-cc          0x0000000000000016 start + 4294807406
Stack dump:
0.      Program arguments: /Users/rdm/llvm/inst/bin/../libexec/clang-cc 
-triple x86_64-apple-darwin10 -emit-pch -disable-free -main-file-name 
myclass.h --relocation-model pic -pic-level=1 --disable-fp-elim 
--unwind-tables=1 --mcpu=core2 --fmath-errno=0 -mmacosx-version-min=10.6 
-fexceptions -fdiagnostics-show-option -o myclass.h.gch -x c++-header 
myclass.h
1.      <eof> parser at end of file
clang: error: precompiler command failed due to signal 6 (use -v to see 
invocation)


For the attached trivial myclass.h.


Cheers, Fons.

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: myclass.h
Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/fd2e7842/attachment.h 

From Fons.Rademakers at cern.ch  Mon Oct  5 20:13:32 2009
From: Fons.Rademakers at cern.ch (Fons Rademakers)
Date: Tue, 6 Oct 2009 03:13:32 +0200
Subject: [cfe-dev] pch generation of C++ header failure...
In-Reply-To: <4ACA94AE.9090502@cern.ch>
References: <4ACA94AE.9090502@cern.ch>
Message-ID: <4ACA99BC.9090700@cern.ch>

To follow up. The assert seems to be due to any content in an inline 
function body. This works fine:

class myclass {
    int fInt;
    double fD;
public:
    myclass() : fInt(10), fD(1.1) { }
    virtual ~myclass() { }
};

and this does not work:

class myclass {
    int fInt;
    double fD;
public:
    myclass() { fInt = 10; fD = 1.1; }
    virtual ~myclass() { }
};

Is this expected? During the dev-meeting it was reported that 80% of the 
Qt4 headers could already be parsed. What statement was used to do that? 
Something like:

clang-cc -x=c++-header -fsyntax-only myclass.h   ?


Cheers, Fons.



Fons Rademakers wrote:
> Hi,
> 
>   should pch generation for a simple C++ class already work in clang 
> (trunk of today)?
> 
> I try:
> 
> clang -x c++-header myclass.h
> 
> which gives an assert error:
> 
> Assertion failed: (Writer.Code != pch::STMT_NULL_PTR && "Unhandled 
> expression writing PCH file"), function WriteSubStmt, file 
> /Users/rdm/llvm/src/tools/clang/lib/Frontend/PCHWriterStmt.cpp, line 834.
> 0   clang-cc          0x0000000100ccfee7 PrintStackTrace(void*) + 38
> 1   clang-cc          0x0000000100cd0475 SignalHandler(int) + 336
> 2   libSystem.B.dylib 0x00007fff882480aa _sigtramp + 26
> 3   libSystem.B.dylib 0x00007fff881ecb2a tiny_malloc_from_free_list + 1196
> 4   libSystem.B.dylib 0x00007fff882c40b4 __pthread_markcancel + 0
> 5   clang-cc          0x00000001000b590c 
> clang::PCHWriter::WriteSubStmt(clang::Stmt*) + 232
> 6   clang-cc          0x00000001000b7318 (anonymous 
> namespace)::PCHStmtWriter::VisitMemberExpr(clang::MemberExpr*) + 54
> 7   clang-cc          0x00000001000b50f2 clang::StmtVisitor<(anonymous 
> namespace)::PCHStmtWriter, void>::Visit(clang::Stmt*) + 2742
> 8   clang-cc          0x00000001000b58d9 
> clang::PCHWriter::WriteSubStmt(clang::Stmt*) + 181
> 9   clang-cc          0x00000001000b6b4a (anonymous 
> namespace)::PCHStmtWriter::VisitBinaryOperator(clang::BinaryOperator*) + 54
> 10  clang-cc          0x00000001000b6e57 clang::StmtVisitor<(anonymous 
> namespace)::PCHStmtWriter, void>::VisitBinAssign(clang::BinaryOperator*) 
> + 29
> 11  clang-cc          0x00000001000b48f7 clang::StmtVisitor<(anonymous 
> namespace)::PCHStmtWriter, void>::Visit(clang::Stmt*) + 699
> 12  clang-cc          0x00000001000b58d9 
> clang::PCHWriter::WriteSubStmt(clang::Stmt*) + 181
> 13  clang-cc          0x00000001000b82b0 (anonymous 
> namespace)::PCHStmtWriter::VisitCompoundStmt(clang::CompoundStmt*) + 112
> 14  clang-cc          0x00000001000b4dd4 clang::StmtVisitor<(anonymous 
> namespace)::PCHStmtWriter, void>::Visit(clang::Stmt*) + 1944
> 15  clang-cc          0x00000001000b56f3 clang::PCHWriter::FlushStmts() 
> + 253
> 16  clang-cc          0x00000001000b2c86 
> clang::PCHWriter::WriteDeclsBlock(clang::ASTContext&) + 846
> 17  clang-cc          0x00000001000a48cb 
> clang::PCHWriter::WritePCH(clang::Sema&, clang::MemorizeStatCalls*, char 
> const*) + 1701
> 18  clang-cc          0x0000000100055bee (anonymous 
> namespace)::PCHGenerator::HandleTranslationUnit(clang::ASTContext&) + 256
> 19  clang-cc          0x00000001002847e0 
> clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, 
> clang::ASTContext&, bool, bool, clang::CodeCompleteConsumer* 
> (*)(clang::Sema&, void*), void*) + 760
> 20  clang-cc          0x000000010002ba21 
> ProcessInputFile(clang::Preprocessor&, clang::PreprocessorFactory&, 
> std::string const&, ProgActions, llvm::StringMap<bool, 
> llvm::MallocAllocator> const&, llvm::LLVMContext&) + 3664
> 21  clang-cc          0x000000010002d137 main + 3269
> 22  clang-cc          0x00000001000270dc start + 52
> 23  clang-cc          0x0000000000000016 start + 4294807406
> Stack dump:
> 0.      Program arguments: /Users/rdm/llvm/inst/bin/../libexec/clang-cc 
> -triple x86_64-apple-darwin10 -emit-pch -disable-free -main-file-name 
> myclass.h --relocation-model pic -pic-level=1 --disable-fp-elim 
> --unwind-tables=1 --mcpu=core2 --fmath-errno=0 -mmacosx-version-min=10.6 
> -fexceptions -fdiagnostics-show-option -o myclass.h.gch -x c++-header 
> myclass.h
> 1.      <eof> parser at end of file
> clang: error: precompiler command failed due to signal 6 (use -v to see 
> invocation)
> 
> 
> For the attached trivial myclass.h.
> 
> 
> Cheers, Fons.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640

From john.thompson.jtsoftware at gmail.com  Mon Oct  5 21:15:14 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Mon, 5 Oct 2009 19:15:14 -0700
Subject: [cfe-dev] Complex literals and VS mode?
In-Reply-To: <FFE0394D-42DE-4067-9026-D41ABB9445DC@apple.com>
References: <aad8390910011634o289790b6gca34995be3acf5f0@mail.gmail.com>
	<FFE0394D-42DE-4067-9026-D41ABB9445DC@apple.com>
Message-ID: <aad8390910051915s6ce2b9d5x47c6dc55e3a30601@mail.gmail.com>

Here's another crack at it, without the goto's.

(Sorry for the duplicate, Doug.)

-John

On Mon, Oct 5, 2009 at 3:14 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Oct 1, 2009, at 4:34 PM, John Thompson wrote:
>
> Three tests are failing on Windows because complex literals (suffix 'i')
>> appear not to be supported when the Microsoft emulation option is on (which
>> it is by default for the Visual Studio-built version).
>>
>
> I don't know anything about complex literals in general, or if this was
>> intentional, or whether it is supported in VC++, but the enclosed patch
>> makes the following tests pass:
>>
>
> Yes, we should support complex literals even in Microsoft emulation mode.
> However, I'd really rather not have a "goto" in this code... could you
> replace that goto with some kind of "WasMicrosoftSuffix" bool?
>
>        - Doug
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/a1f5b07b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32complexconstants.patch
Type: application/octet-stream
Size: 3332 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/a1f5b07b/attachment-0001.obj 

From ob at bitmover.com  Mon Oct  5 23:46:18 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Mon, 5 Oct 2009 21:46:18 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
	<A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
	<6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>
Message-ID: <CC5CD715-4884-4C00-BD9C-3232B10D7478@bitmover.com>

On Oct 5, 2009, at 2:39 PM, Douglas Gregor wrote:
> This condition:
>
> +    if (isa<VarDecl>(D) && !isa<ParmVarDecl>(D) &&
> +	!D->isUsed() && !D->hasAttr<UnusedAttr>())
> +	    Diag(D->getLocation(), diag::warn_unused_variable) << D- 
> >getDeclName();
>
> is a good start, but I think you only want to complain about  
> function-local variables, e.g., by checking that
>
> 	D->getDeclContext()->isFunctionOrMethod()
>
> There are a few other issues that need to be resolved:
>
>  1) If a variable is only used in an unevaluated context (such as  
> the operand of a sizeof expression), it will incorrectly complain  
> that the variable is unused:
>
> void g() {
>  int i;
>  (void)sizeof(i);
> }
>
>  2) It incorrectly complains about variables in templates:
>
> template<typename T> void f() {
>  T t;
>  t = 17;
> }
>
> With this warning, it makes sense to enable the warning when  
> compiling a small-to-medium---sized C application and then look at  
> where the warning triggers. Did it complain too often? Did GCC  
> correctly complain about something that Clang missed?

That's how I found my previous error, I compiled a product that I'm  
working on and got all sorts of warnings. The problem is that "normal"  
code doesn't have unused variables, so you have to artificially  
introduce them or compile new code with it.

My first thought was that parameters should have the same problem, but  
they are special-cased in MarkDeclaraionReferenced(). I added a  
special case for Variables too, is this right?

Here's what I have:

The patch: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ob.patch
Type: application/octet-stream
Size: 1955 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/6a04a149/attachment.obj 
-------------- next part --------------

The testcases:
llvm/tools/clang/test/Sema/warn-unused-variables.c 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warn-unused-variables.c
Type: application/octet-stream
Size: 265 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/6a04a149/attachment-0001.obj 
-------------- next part --------------

llvm/tools/clang/test/SemaCXX/warn-unused-variables.c 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warn-unused-variables.cpp
Type: application/octet-stream
Size: 107 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091005/6a04a149/attachment-0002.obj 
-------------- next part --------------


Is this any better?

Cheers,

-Oscar

P.S. I will wait for your okay before updating the bug report this  
time :)


From ob at bitmover.com  Tue Oct  6 01:37:47 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Mon, 5 Oct 2009 23:37:47 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <CC5CD715-4884-4C00-BD9C-3232B10D7478@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
	<A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
	<6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>
	<CC5CD715-4884-4C00-BD9C-3232B10D7478@bitmover.com>
Message-ID: <2596256F-DC97-407C-A25E-980D492AF6E0@bitmover.com>

On Oct 5, 2009, at 9:46 PM, Oscar Bonilla wrote:

> Is this any better?

Still not quite right:

$ clang-cc test/SemaObjC/unused.m  -verify -Wunused -fsyntax-only
Warnings seen but not expected:
   Line 0: unused variable 'self'
   Line 0: unused variable '_cmd'
   Line 0: unused variable 'self'
   Line 0: unused variable '_cmd'
   Line 41: unused variable 'y'

Sigh. I'll look at this tomorrow...

Cheers,

-Oscar


From abramobagnara at tin.it  Tue Oct  6 02:42:23 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Tue, 06 Oct 2009 09:42:23 +0200
Subject: [cfe-dev] Generation of CallExpr to builtin function
In-Reply-To: <91B635AC-C90A-44AE-B711-1E78496AE967@apple.com>
References: <4ACA0890.1020903@tin.it>
	<91B635AC-C90A-44AE-B711-1E78496AE967@apple.com>
Message-ID: <4ACAF4DF.1040400@tin.it>

Douglas Gregor ha scritto:
> 
> On Oct 5, 2009, at 7:54 AM, Abramo Bagnara wrote:
> 
>>
>> In our application we need to generate a new CallExpr to a builtin
>> function, but we are unable to find a way to do that.
>>
>> In SemaDecl.cpp we have found
>>
>> /// LazilyCreateBuiltin - The specified Builtin-ID was first used at
>> /// file scope.  lazily create a decl for it. ForRedeclaration is true
>> /// if we're creating this built-in in anticipation of redeclaring the
>> /// built-in.
>> NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II, unsigned bid,
>>                                     Scope *S, bool ForRedeclaration,
>>                                     SourceLocation Loc);
>>
>> but it's inaccessible (and does also other things).
>>
>> What's the right way to do that?
> 
> You can find the built-in function using Sema::ActOnIdentifierExpr,
> which will have the effect of implicitly declaring the builtin (or
> finding it if it already existed) and then building a DeclRefExpr that
> you can use as the callee of your call expression.

Sorry, I think I have not explained well the problem.

What we need is a way for a program that uses clang as a library to
create a CallExpr to a builtin function.

Of course inside clang we would be able to use Sema to do that, but this
is not the case.

I think that having something similar to

NamedDecl* ASTContext::BuiltinDecl(IdentifierInfo *II, Builtin::ID BID);

could be a solution.


From dgregor at apple.com  Tue Oct  6 09:50:24 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 6 Oct 2009 07:50:24 -0700
Subject: [cfe-dev] pch generation of C++ header failure...
In-Reply-To: <4ACA94AE.9090502@cern.ch>
References: <4ACA94AE.9090502@cern.ch>
Message-ID: <5766D684-7B52-417D-B5CB-631ED3C0AA84@apple.com>


On Oct 5, 2009, at 5:51 PM, Fons Rademakers wrote:

> Hi,
>
>  should pch generation for a simple C++ class already work in clang  
> (trunk of today)?

No. PCH is only implemented for C and Objective-C so far.

	- Doug

From dgregor at apple.com  Tue Oct  6 10:03:31 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 6 Oct 2009 08:03:31 -0700
Subject: [cfe-dev] Generation of CallExpr to builtin function
In-Reply-To: <4ACAF4DF.1040400@tin.it>
References: <4ACA0890.1020903@tin.it>
	<91B635AC-C90A-44AE-B711-1E78496AE967@apple.com>
	<4ACAF4DF.1040400@tin.it>
Message-ID: <667369CF-5074-4995-9D47-29B7B897134C@apple.com>


On Oct 6, 2009, at 12:42 AM, Abramo Bagnara wrote:

> Douglas Gregor ha scritto:
>>
>> On Oct 5, 2009, at 7:54 AM, Abramo Bagnara wrote:
>>
>>>
>>> In our application we need to generate a new CallExpr to a builtin
>>> function, but we are unable to find a way to do that.
>>>
>>> In SemaDecl.cpp we have found
>>>
>>> /// LazilyCreateBuiltin - The specified Builtin-ID was first used at
>>> /// file scope.  lazily create a decl for it. ForRedeclaration is  
>>> true
>>> /// if we're creating this built-in in anticipation of redeclaring  
>>> the
>>> /// built-in.
>>> NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II, unsigned  
>>> bid,
>>>                                    Scope *S, bool ForRedeclaration,
>>>                                    SourceLocation Loc);
>>>
>>> but it's inaccessible (and does also other things).
>>>
>>> What's the right way to do that?
>>
>> You can find the built-in function using Sema::ActOnIdentifierExpr,
>> which will have the effect of implicitly declaring the builtin (or
>> finding it if it already existed) and then building a DeclRefExpr  
>> that
>> you can use as the callee of your call expression.
>
> Sorry, I think I have not explained well the problem.
>
> What we need is a way for a program that uses clang as a library to
> create a CallExpr to a builtin function.
>
> Of course inside clang we would be able to use Sema to do that, but  
> this
> is not the case.

Ah, okay.

> I think that having something similar to
>
> NamedDecl* ASTContext::BuiltinDecl(IdentifierInfo *II, Builtin::ID  
> BID);
>
> could be a solution.

This would be a useful refactoring. The IdentifierInfo itself knows  
whether it is a builtin, so BuiltinDecl could just take an  
IdentifierInfo pointer or reference. Will you provide a patch that  
provides this function?

	- Doug


From ob at bitmover.com  Tue Oct  6 11:12:36 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Tue, 6 Oct 2009 09:12:36 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <2596256F-DC97-407C-A25E-980D492AF6E0@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
	<A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
	<6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>
	<CC5CD715-4884-4C00-BD9C-3232B10D7478@bitmover.com>
	<2596256F-DC97-407C-A25E-980D492AF6E0@bitmover.com>
Message-ID: <8A40E756-DB19-41AE-AEFF-C5E913E563E3@bitmover.com>

On Oct 5, 2009, at 11:37 PM, Oscar Bonilla wrote:

> On Oct 5, 2009, at 9:46 PM, Oscar Bonilla wrote:
>
>> Is this any better?
>
> Still not quite right:

Ok, this one seems to do the trick:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ob.patch
Type: application/octet-stream
Size: 2081 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/0d50c08a/attachment.obj 
-------------- next part --------------


Testcases:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: warn-unused-variables.c
Type: application/octet-stream
Size: 268 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/0d50c08a/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warn-unused-variables.cpp
Type: application/octet-stream
Size: 107 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/0d50c08a/attachment-0002.obj 
-------------- next part --------------


I ran "make test" and only got one failure:

FAIL: Clang::Index/c-index-api-test.m (646 of 1636)

which seems unrelated. I also compiled Adium with it and didn't get  
any obvious false positives or false negatives.

Cheers,

-Oscar


From ob at bitmover.com  Tue Oct  6 12:15:25 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Tue, 6 Oct 2009 10:15:25 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <8A40E756-DB19-41AE-AEFF-C5E913E563E3@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
	<A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
	<6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>
	<CC5CD715-4884-4C00-BD9C-3232B10D7478@bitmover.com>
	<2596256F-DC97-407C-A25E-980D492AF6E0@bitmover.com>
	<8A40E756-DB19-41AE-AEFF-C5E913E563E3@bitmover.com>
Message-ID: <31276601-5A11-47C8-A0C5-2BA6ED80E6B0@bitmover.com>

On Oct 6, 2009, at 9:12 AM, Oscar Bonilla wrote:

> On Oct 5, 2009, at 11:37 PM, Oscar Bonilla wrote:
>
>> On Oct 5, 2009, at 9:46 PM, Oscar Bonilla wrote:
>>
>>> Is this any better?
>>
>> Still not quite right:
>
> Ok, this one seems to do the trick:
>
> <ob.patch>
>
> Testcases:
>
> <warn-unused-variables.c><warn-unused-variables.cpp>
>
> I ran "make test" and only got one failure:
>
> FAIL: Clang::Index/c-index-api-test.m (646 of 1636)
>
> which seems unrelated. I also compiled Adium with it and didn't get  
> any obvious false positives or false negatives.
>

Would it be better to write the if in SemaDecl.cpp

     if (isa<VarDecl>(D) && !isa<ParmVarDecl>(D) && ! 
isa<ImplicitParamDecl>(D) &&
	D->getDeclContext()->isFunctionOrMethod() &&
	!D->isUsed() && !D->hasAttr<UnusedAttr>()) {
	    Diag(D->getLocation(), diag::warn_unused_variable) << D- 
 >getDeclName();
     }

as

     if (!D->isUsed() && !D->hasAttr<UnusedAttr>() &&
	isa<VarDecl>(D) && !isa<ParmVarDecl>(D) && !isa<ImplicitParamDecl>(D)  
&&
	D->getDeclContext()->isFunctionOrMethod()) {
	    Diag(D->getLocation(), diag::warn_unused_variable) << D- 
 >getDeclName();
     }

i.e. move the "not used and no unused attr" to the beginning to take  
advantage of short-circuit logic?

or is this kind of micro-optimizing frowned upon? :)

Cheers,

-Oscar


From Fons.Rademakers at cern.ch  Tue Oct  6 14:16:00 2009
From: Fons.Rademakers at cern.ch (Fons Rademakers)
Date: Tue, 6 Oct 2009 21:16:00 +0200
Subject: [cfe-dev] pch generation of C++ header failure...
In-Reply-To: <EA80A888-C647-4BA0-BF09-23B34D703D70@apple.com>
References: <4ACA94AE.9090502@cern.ch>
	<5766D684-7B52-417D-B5CB-631ED3C0AA84@apple.com>
	<4ACB6C17.1030407@cern.ch>
	<6D055817-4366-4CDA-A38A-F9ADC5C6F3B7@apple.com>
	<4ACB810C.9090209@cern.ch>
	<EA80A888-C647-4BA0-BF09-23B34D703D70@apple.com>
Message-ID: <4ACB9770.1060000@cern.ch>

Hi Doug,

  thanks for the prompt answers. Really helps us going... Axel will be 
working on querying the AST so I hope he will be able to help plug a lot of 
holes (soon).

Concerning the partial template specialization issue any known ETA? Due to 
this assertion there are about 70 of the 1250 headers that fail. Very 
encouraging.


Cheers, Fons.


Douglas Gregor wrote:
> 
> On Oct 6, 2009, at 10:40 AM, Fons Rademakers wrote:
> 
>> Ok, that makes sense. ;-) I am currently checking our C++ project headers
>> to see if they parse correctly. I use:
>>
>> clang-cc -x=c++-header -fsyntax-only myheader.h
>>
>> is that the correct command to check the C++ parser?
> 
> Yes, that works. I tend to use
> 
>     clang -x c++ -fsyntax-only myheader.h
> 
>> In a number of our
>> 1250 headers I get:
>>
>> ====== root/include/TGeoCache.h =========
>> Assertion failed: (Access != AS_none && "Access specifier is AS_none 
>> inside
>> a record decl"), function CheckAccessDeclContext, file
>> /Users/rdm/llvm/src/tools/clang/lib/AST/DeclBase.cpp, line 401.
>> 0   clang-cc          0x0000000100ccfee7 PrintStackTrace(void*) + 38
>> 1   clang-cc          0x0000000100cd0475 SignalHandler(int) + 336
>> 2   libSystem.B.dylib 0x00007fff882480aa _sigtramp + 26
>> 3   clang-cc          0x00000001002849aa
>> clang::DeclarationName::getTombstoneMarker() + 24
>> 4   libSystem.B.dylib 0x00007fff882c40b4 __pthread_markcancel + 0
>> 5   clang-cc          0x00000001003e534d
>> clang::Decl::CheckAccessDeclContext() const + 135
>> 6   clang-cc          0x00000001003af121 clang::Decl::getAccess() 
>> const + 21
>> 7   clang-cc          0x00000001003a9d21 (anonymous
>> namespace)::TemplateDeclInstantiator::VisitCXXRecordDecl(clang::CXXRecordDecl*) 
>>
>> + 193
>> 8   clang-cc          0x00000001003a9dd5 clang::DeclVisitor<(anonymous
>> namespace)::TemplateDeclInstantiator,
>> clang::Decl*>::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) 
>>
>> + 29
>> 9   clang-cc          0x00000001003a9df5 clang::DeclVisitor<(anonymous
>> namespace)::TemplateDeclInstantiator,
>> clang::Decl*>::VisitClassTemplatePartialSpecializationDecl(clang::ClassTemplatePartialSpecializationDecl*) 
>>
>> + 29
>>
>> which the most common assert I encounter. Any idea which construct 
>> causes this?
> 
> This is probably because we aren't yet able to instantiate class 
> template partial specializations that occur within a class template. 
> This feature is used in libstdc++'s <map>.
> 
>> Other question, if they parse correctly, does that mean that the AST is
>> correct/complete and that we should be able to query the class properties
>> (list of data members, methods, etc) via the AST API?
> 
> 
> In theory, yes. In practice, there's lots of debugging to do and there 
> are still many holes to plug. We could use some help!
> 
>     - Doug

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640

From dgregor at apple.com  Tue Oct  6 15:43:55 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 6 Oct 2009 13:43:55 -0700
Subject: [cfe-dev] pch generation of C++ header failure...
In-Reply-To: <4ACB9770.1060000@cern.ch>
References: <4ACA94AE.9090502@cern.ch>
	<5766D684-7B52-417D-B5CB-631ED3C0AA84@apple.com>
	<4ACB6C17.1030407@cern.ch>
	<6D055817-4366-4CDA-A38A-F9ADC5C6F3B7@apple.com>
	<4ACB810C.9090209@cern.ch>
	<EA80A888-C647-4BA0-BF09-23B34D703D70@apple.com>
	<4ACB9770.1060000@cern.ch>
Message-ID: <7A3E858D-9E40-4C13-BAB4-E1B476D2752E@apple.com>


On Oct 6, 2009, at 12:16 PM, Fons Rademakers wrote:
> thanks for the prompt answers. Really helps us going... Axel will be  
> working on querying the AST so I hope he will be able to help plug a  
> lot of holes (soon).

Okay!

> Concerning the partial template specialization issue any known ETA?  
> Due to this assertion there are about 70 of the 1250 headers that  
> fail. Very encouraging.


A week, maybe? It's queued behind a few other features and fixes in  
the template system.

	- Doug

From ladybhaal at gmail.com  Tue Oct  6 15:58:49 2009
From: ladybhaal at gmail.com (Michelle Bhaal)
Date: Wed, 7 Oct 2009 07:58:49 +1100
Subject: [cfe-dev] Error compiling clang on Windows,
	DiagnosticCommonKinds.inc 	not found
In-Reply-To: <5622FE6B-3BF7-40A0-83E1-53F713C11123@apple.com>
References: <5b344ead0910030243y5df1aad5q7eda240e788cb039@mail.gmail.com>
	<5622FE6B-3BF7-40A0-83E1-53F713C11123@apple.com>
Message-ID: <5b344ead0910061358g546fe09es4da7f79f782786b@mail.gmail.com>

It's only failing on
llvm\tools\clang\include\clang/Basic/Diagnostic.h(56) for the missing
file now, but I also get a lot of other errors, mostly the same type.
I've included my output so you can see for yourself.

2009/10/6 Douglas Gregor <dgregor at apple.com>:
>
> On Oct 3, 2009, at 2:43 AM, Michelle Bhaal wrote:
>
>> I have downloaded clang (83246) and llvm (83257) via subversion. ?I
>> used cmake 2.8 beta to create a solution file for Visual Studio 2010
>> beta and attempted to compile clang-cc but I repeatedly get the
>> following error:
>>
>> fatal error C1083: Cannot open include file:
>> 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
>
> What file(s) is it trying to compile when you hit this error? It's possible
> that we're missing dependencies, but I know there are at least a few Visual
> Studio users around who are able to build Clang.
>
> ? ? ? ?- Doug
>
-------------- next part --------------
1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
1>Build started 7/10/2009 7:46:19 AM.
1>_PrepareForBuild:
1>  Touching "Debug\lastbuild.timestamp".
1>CustomBuild:
1>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
1>_AfterBuild:
1>  Creating "Debug\LastSuccessfulBuild.timestamp" because "AlwaysCreate" was specified.
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.02
2>------ Build started: Project: LLVMSupport, Configuration: Debug Win32 ------
2>Build started 7/10/2009 7:46:20 AM.
2>IsProjectFileNewer:
2>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
2>_PrepareForBuild:
2>  Touching "LLVMSupport.dir\Debug\lastbuild.timestamp".
3>------ Build started: Project: clang-headers, Configuration: Debug Win32 ------
4>------ Skipped Build: Project: llvm-test, Configuration: Debug Win32 ------
4>Project not selected to build for this solution configuration 
5>------ Build started: Project: llvm_headers_do_not_build, Configuration: Debug Win32 ------
3>Build started 7/10/2009 7:46:21 AM.
3>IsProjectFileNewer:
3>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
3>_PrepareForBuild:
3>  Touching "Debug\lastbuild.timestamp".
2>CustomBuild:
2>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
3>CustomBuild:
3>  Description: Copying clang's emmintrin.h...
5>Build started 7/10/2009 7:46:21 AM.
5>_PrepareForBuild:
5>  Creating directory "llvm_headers_do_not_build.dir\Debug\".
3>CustomBuild:
3>  Description: Copying clang's float.h...
5>  Creating "llvm_headers_do_not_build.dir\Debug\lastbuild.timestamp" because "AlwaysCreate" was specified.
2>ClCompile:
2>  CommandLine.cpp
5>CustomBuild:
5>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
3>CustomBuild:
3>  Description: Copying clang's iso646.h...
5>ClCompile:
5>  Hello.cpp
3>CustomBuild:
3>  Description: Copying clang's limits.h...
3>CustomBuild:
3>  Description: Copying clang's mm_malloc.h...
3>CustomBuild:
3>  Description: Copying clang's mmintrin.h...
3>CustomBuild:
3>  Description: Copying clang's pmmintrin.h...
3>CustomBuild:
3>  Description: Copying clang's stdarg.h...
3>CustomBuild:
3>  Description: Copying clang's stdbool.h...
3>CustomBuild:
3>  Description: Copying clang's stddef.h...
3>CustomBuild:
3>  Description: Copying clang's stdint.h...
3>CustomBuild:
3>  Description: Copying clang's tgmath.h...
3>CustomBuild:
3>  Description: Copying clang's tmmintrin.h...
3>CustomBuild:
3>  Description: Copying clang's xmmintrin.h...
3>CustomBuild:
3>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
3>_AfterBuild:
3>  Touching "Debug\LastSuccessfulBuild.timestamp".
3>
3>Build succeeded.
3>
3>Time Elapsed 00:00:01.81
2>  ConstantRange.cpp
5>Lib:
5>  llvm_headers_do_not_build.vcxproj -> C:\Temp\llvm\lib\Debug\llvm_headers_do_not_build.lib
2>  Triple.cpp
2>  Generating Code...
2>  Skipping task because its outputs are up-to-date.
2>Lib:
2>  LLVMSupport.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMSupport.lib
2>_AfterBuild:
2>  Touching "LLVMSupport.dir\Debug\LastSuccessfulBuild.timestamp".
2>
2>Build succeeded.
2>
2>Time Elapsed 00:00:05.29
5>_AfterBuild:
5>  Creating "llvm_headers_do_not_build.dir\Debug\LastSuccessfulBuild.timestamp" because "AlwaysCreate" was specified.
5>
5>Build succeeded.
5>
5>Time Elapsed 00:00:04.22
6>------ Build started: Project: tblgen, Configuration: Debug Win32 ------
6>Build started 7/10/2009 7:46:25 AM.
6>IsProjectFileNewer:
6>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
6>_PrepareForBuild:
6>  Touching "tblgen.dir\Debug\lastbuild.timestamp".
6>CustomBuild:
6>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
6>ClCompile:
6>  Skipping task because its outputs are up-to-date.
6>ManifestResourceCompile:
6>  Skipping task because its outputs are up-to-date.
7>------ Build started: Project: FileCheck, Configuration: Debug Win32 ------
7>Build started 7/10/2009 7:46:25 AM.
7>IsProjectFileNewer:
7>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
7>_PrepareForBuild:
7>  Touching "FileCheck.dir\Debug\lastbuild.timestamp".
7>CustomBuild:
7>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
7>ClCompile:
7>  FileCheck.cpp
7>ManifestResourceCompile:
7>  Skipping task because its outputs are up-to-date.
7>Manifest:
7>  Skipping task because its outputs are up-to-date.
7>LinkEmbedManifest:
7>  Skipping task because its outputs are up-to-date.
7>  FileCheck.vcxproj -> C:\Temp\llvm\bin\Debug\FileCheck.exe
6>Link:
6>     Creating library C:/Temp/llvm/lib/Debug/tblgen.lib and object C:/Temp/llvm/lib/Debug/tblgen.exp
6>Manifest:
6>  Skipping task because its outputs are up-to-date.
6>LinkEmbedManifest:
6>  Skipping task because its outputs are up-to-date.
6>  tblgen.vcxproj -> C:\Temp\llvm\bin\Debug\tblgen.exe
7>_AfterBuild:
7>  Touching "FileCheck.dir\Debug\LastSuccessfulBuild.timestamp".
7>
7>Build succeeded.
7>
7>Time Elapsed 00:00:07.17
6>_AfterBuild:
6>  Touching "tblgen.dir\Debug\LastSuccessfulBuild.timestamp".
6>
6>Build succeeded.
6>
6>Time Elapsed 00:00:07.49
8>------ Build started: Project: X86CodeGenTable_gen, Configuration: Debug Win32 ------
8>Build started 7/10/2009 7:46:33 AM.
8>_PrepareForBuild:
8>  Touching "Debug\lastbuild.timestamp".
9>------ Build started: Project: LLVMipa, Configuration: Debug Win32 ------
9>Build started 7/10/2009 7:46:33 AM.
9>IsProjectFileNewer:
9>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
9>_PrepareForBuild:
9>  Touching "LLVMipa.dir\Debug\lastbuild.timestamp".
10>------ Build started: Project: LLVMBitWriter, Configuration: Debug Win32 ------
8>CustomBuild:
10>Build started 7/10/2009 7:46:33 AM.
10>IsProjectFileNewer:
10>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
10>_PrepareForBuild:
10>  Touching "LLVMBitWriter.dir\Debug\lastbuild.timestamp".
8>  Description: Building X86GenRegisterInfo.h.inc...
11>------ Build started: Project: LLVMBitReader, Configuration: Debug Win32 ------
11>Build started 7/10/2009 7:46:33 AM.
11>IsProjectFileNewer:
11>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
11>_PrepareForBuild:
11>  Touching "LLVMBitReader.dir\Debug\lastbuild.timestamp".
8>CustomBuild:
8>  Description: Building X86GenRegisterNames.inc...
8>CustomBuild:
8>  Description: Building X86GenRegisterInfo.inc...
8>CustomBuild:
8>  Description: Building X86GenInstrNames.inc...
8>CustomBuild:
8>  Description: Building X86GenInstrInfo.inc...
8>CustomBuild:
8>  Description: Building X86GenAsmWriter.inc...
8>CustomBuild:
8>  Description: Building X86GenAsmWriter1.inc...
8>CustomBuild:
8>  Description: Building X86GenAsmMatcher.inc...
8>CustomBuild:
8>  Description: Building X86GenDAGISel.inc...
8>CustomBuild:
8>  Description: Building X86GenFastISel.inc...
8>CustomBuild:
8>  Description: Building X86GenCallingConv.inc...
8>CustomBuild:
8>  Description: Building X86GenSubtarget.inc...
8>CustomBuild:
8>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
8>_AfterBuild:
8>  Touching "Debug\LastSuccessfulBuild.timestamp".
8>
8>Build succeeded.
8>
8>Time Elapsed 00:01:11.90
9>CustomBuild:
9>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
10>CustomBuild:
10>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
10>ClCompile:
10>  BitWriter.cpp
9>ClCompile:
9>  Andersens.cpp
12>------ Build started: Project: LLVMX86CodeGen, Configuration: Debug Win32 ------
12>Build started 7/10/2009 7:47:45 AM.
12>_PrepareForBuild:
12>  Touching "LLVMX86CodeGen.dir\Debug\lastbuild.timestamp".
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>CustomBuild:
12>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
12>ClCompile:
12>  X86CodeEmitter.cpp
10>  BitcodeWriter.cpp
9>  CallGraph.cpp
10>  ValueEnumerator.cpp
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>  X86COFFMachineModuleInfo.cpp
9>  CallGraphSCCPass.cpp
10>  Generating Code...
10>Lib:
10>  LLVMBitWriter.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMBitWriter.lib
11>CustomBuild:
11>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
11>ClCompile:
11>  BitReader.cpp
12>  X86ELFWriterInfo.cpp
9>  FindUsedTypes.cpp
12>  X86FloatingPoint.cpp
9>  GlobalsModRef.cpp
11>  BitcodeReader.cpp
12>X86FloatingPoint.cpp(296): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::MachineBasicBlock::iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::MachineBasicBlock::iterator
12>          ]
12>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
12>X86FloatingPoint.cpp(296): fatal error C1903: unable to recover from previous error(s); stopping compilation
12>  X86FloatingPointRegKill.cpp
11>  Generating Code...
9>  Generating Code...
11>Lib:
11>  LLVMBitReader.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMBitReader.lib
12>  X86ISelDAGToDAG.cpp
9>Lib:
9>  LLVMipa.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMipa.lib
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>C:\Temp\llvm\include\llvm/CodeGen/DAGISelHeader.h(96): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::ilist_iterator<llvm::SDNode>,
12>              NodeTy=llvm::SDNode
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)'
12>          with
12>          [
12>              _InIt=llvm::ilist_iterator<llvm::SDNode>,
12>              NodeTy=llvm::SDNode
12>          ]
12>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
12>          with
12>          [
12>              NodeTy=llvm::SDNode
12>          ]
12>  X86ISelLowering.cpp
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>  X86InstrInfo.cpp
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>X86InstrInfo.cpp(1546): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::MachineBasicBlock::iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::MachineBasicBlock::iterator
12>          ]
12>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
12>X86InstrInfo.cpp(1546): fatal error C1903: unable to recover from previous error(s); stopping compilation
12>  X86JITInfo.cpp
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>  X86MCAsmInfo.cpp
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>  X86RegisterInfo.cpp
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>X86RegisterInfo.cpp(730): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::MachineBasicBlock::iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)'
12>          with
12>          [
12>              _InIt=llvm::MachineBasicBlock::iterator
12>          ]
12>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
12>X86RegisterInfo.cpp(764): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::MachineBasicBlock::iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)'
12>          with
12>          [
12>              _InIt=llvm::MachineBasicBlock::iterator
12>          ]
12>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
12>X86RegisterInfo.cpp(990): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineFunction::iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::MachineFunction::iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineFunction::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::MachineFunction::iterator
12>          ]
12>          while trying to match the argument list '(llvm::MachineFunction::iterator)'
12>  X86Subtarget.cpp
12>  X86TargetMachine.cpp
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>  X86TargetObjectFile.cpp
12>  X86FastISel.cpp
12>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
12>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
12>          with
12>          [
12>              ItTy=llvm::SDNode::use_iterator
12>          ]
12>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
12>          with
12>          [
12>              _InIt=llvm::SDNode::use_iterator
12>          ]
12>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
12>  Generating Code...
12>
12>Build FAILED.
12>
12>Time Elapsed 00:00:28.31
11>_AfterBuild:
11>  Touching "LLVMBitReader.dir\Debug\LastSuccessfulBuild.timestamp".
11>
11>Build succeeded.
11>
11>Time Elapsed 00:01:40.35
10>_AfterBuild:
9>_AfterBuild:
9>  Touching "LLVMipa.dir\Debug\LastSuccessfulBuild.timestamp".
9>
9>Build succeeded.
9>
9>Time Elapsed 00:01:40.60
13>------ Build started: Project: LLVMX86Info, Configuration: Debug Win32 ------
10>  Touching "LLVMBitWriter.dir\Debug\LastSuccessfulBuild.timestamp".
10>
10>Build succeeded.
10>
10>Time Elapsed 00:01:40.51
14>------ Build started: Project: LLVMX86AsmPrinter, Configuration: Debug Win32 ------
13>Build started 7/10/2009 7:48:14 AM.
13>IsProjectFileNewer:
13>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
13>_PrepareForBuild:
13>  Touching "LLVMX86Info.dir\Debug\lastbuild.timestamp".
15>------ Build started: Project: LLVMAsmPrinter, Configuration: Debug Win32 ------
14>Build started 7/10/2009 7:48:14 AM.
14>IsProjectFileNewer:
14>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
14>_PrepareForBuild:
14>  Touching "LLVMX86AsmPrinter.dir\Debug\lastbuild.timestamp".
16>------ Build started: Project: LLVMAnalysis, Configuration: Debug Win32 ------
16>Build started 7/10/2009 7:48:14 AM.
16>IsProjectFileNewer:
16>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
16>_PrepareForBuild:
16>  Touching "LLVMAnalysis.dir\Debug\lastbuild.timestamp".
15>Build started 7/10/2009 7:48:14 AM.
15>IsProjectFileNewer:
15>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
15>_PrepareForBuild:
15>  Touching "LLVMAsmPrinter.dir\Debug\lastbuild.timestamp".
15>CustomBuild:
15>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
16>CustomBuild:
16>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
15>ClCompile:
15>  AsmPrinter.cpp
16>ClCompile:
16>  AliasAnalysis.cpp
16>  AliasAnalysisEvaluator.cpp
15>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
15>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
15>          with
15>          [
15>              ItTy=llvm::SDNode::use_iterator
15>          ]
15>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
15>          with
15>          [
15>              _InIt=llvm::SDNode::use_iterator
15>          ]
15>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
15>  DIE.cpp
16>  AliasDebugger.cpp
15>  DwarfDebug.cpp
16>  AliasSetTracker.cpp
16>  Analysis.cpp
16>  BasicAliasAnalysis.cpp
15>  DwarfException.cpp
16>  CFGPrinter.cpp
15>  DwarfPrinter.cpp
16>  CaptureTracking.cpp
16>  ConstantFolding.cpp
15>  DwarfWriter.cpp
16>  DbgInfoPrinter.cpp
15>  OcamlGCPrinter.cpp
16>  DebugInfo.cpp
15>  Generating Code...
16>  IVUsers.cpp
15>
15>Build FAILED.
15>
15>Time Elapsed 00:00:12.60
17>------ Build started: Project: clangSema, Configuration: Debug Win32 ------
17>Build started 7/10/2009 7:48:26 AM.
17>_PrepareForBuild:
17>  Touching "clangSema.dir\Debug\lastbuild.timestamp".
17>CustomBuild:
17>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
17>ClCompile:
17>  CodeCompleteConsumer.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  IdentifierResolver.cpp
16>  InstCount.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  JumpDiagnostics.cpp
16>  Interval.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  ParseAST.cpp
16>  IntervalPartition.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  Sema.cpp
16>  LiveValues.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaAccess.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaAttr.cpp
16>  LoopDependenceAnalysis.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaCXXCast.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaCXXScopeSpec.cpp
16>  LoopInfo.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaChecking.cpp
16>  LoopPass.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaCodeComplete.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaDecl.cpp
16>  LoopVR.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaDeclAttr.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaDeclCXX.cpp
16>  Generating Code...
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaDeclObjC.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaExpr.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaExprCXX.cpp
16>  Compiling...
16>  MallocHelper.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaExprObjC.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaInit.cpp
16>  MemoryDependenceAnalysis.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaLookup.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  Generating Code...
17>  Compiling...
17>  SemaOverload.cpp
16>  PointerTracking.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaStmt.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaTemplate.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaTemplateDeduction.cpp
16>  PostDominators.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaTemplateInstantiate.cpp
16>  ProfileEstimatorPass.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaTemplateInstantiateDecl.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  SemaType.cpp
16>  ProfileInfo.cpp
17>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
17>  Generating Code...
17>
17>Build FAILED.
17>
17>Time Elapsed 00:00:19.12
18>------ Build started: Project: clangRewrite, Configuration: Debug Win32 ------
18>Build started 7/10/2009 7:48:46 AM.
18>IsProjectFileNewer:
18>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
18>_PrepareForBuild:
18>  Touching "clangRewrite.dir\Debug\lastbuild.timestamp".
18>CustomBuild:
18>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
16>  ProfileInfoLoader.cpp
18>ClCompile:
18>  HTMLRewrite.cpp
18>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
18>  Rewriter.cpp
16>  ProfileInfoLoaderPass.cpp
18>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
18>  Generating Code...
18>
18>Build FAILED.
18>
18>Time Elapsed 00:00:01.56
19>------ Build started: Project: clangParse, Configuration: Debug Win32 ------
19>Build started 7/10/2009 7:48:48 AM.
19>IsProjectFileNewer:
19>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
19>_PrepareForBuild:
19>  Touching "clangParse.dir\Debug\lastbuild.timestamp".
19>CustomBuild:
19>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
19>ClCompile:
19>  DeclSpec.cpp
16>  ProfileVerifierPass.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  MinimalAction.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseCXXInlineMethods.cpp
16>  ScalarEvolution.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseDecl.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseDeclCXX.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseExpr.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseExprCXX.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseInit.cpp
16>  ScalarEvolutionAliasAnalysis.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseObjc.cpp
16>  ScalarEvolutionExpander.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParsePragma.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseStmt.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseTemplate.cpp
16>ScalarEvolutionExpander.cpp(631): error C2668: 'llvm::next' : ambiguous call to overloaded function
16>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
16>          with
16>          [
16>              ItTy=llvm::ilist_iterator<llvm::Instruction>,
16>              NodeTy=llvm::Instruction
16>          ]
16>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
16>          with
16>          [
16>              _InIt=llvm::ilist_iterator<llvm::Instruction>,
16>              NodeTy=llvm::Instruction
16>          ]
16>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
16>          with
16>          [
16>              NodeTy=llvm::Instruction
16>          ]
16>ScalarEvolutionExpander.cpp(847): error C2668: 'llvm::next' : ambiguous call to overloaded function
16>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
16>          with
16>          [
16>              ItTy=llvm::ilist_iterator<llvm::Instruction>,
16>              NodeTy=llvm::Instruction
16>          ]
16>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
16>          with
16>          [
16>              _InIt=llvm::ilist_iterator<llvm::Instruction>,
16>              NodeTy=llvm::Instruction
16>          ]
16>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
16>          with
16>          [
16>              NodeTy=llvm::Instruction
16>          ]
16>  SparsePropagation.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  ParseTentative.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  Parser.cpp
16>  ValueTracking.cpp
19>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
19>  Generating Code...
19>
19>Build FAILED.
19>
19>Time Elapsed 00:00:07.75
20>------ Build started: Project: clangLex, Configuration: Debug Win32 ------
20>Build started 7/10/2009 7:48:56 AM.
20>IsProjectFileNewer:
20>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
20>_PrepareForBuild:
20>  Touching "clangLex.dir\Debug\lastbuild.timestamp".
20>CustomBuild:
20>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
20>ClCompile:
20>  Lexer.cpp
16>  Generating Code...
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  LiteralSupport.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  MacroArgs.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  MacroInfo.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  PPCaching.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  PPDirectives.cpp
16>
16>Build FAILED.
16>
16>Time Elapsed 00:00:45.94
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  PPExpressions.cpp
21>------ Build started: Project: LLVMCodeGen, Configuration: Debug Win32 ------
21>Build started 7/10/2009 7:49:00 AM.
21>IsProjectFileNewer:
21>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
21>_PrepareForBuild:
21>  Touching "LLVMCodeGen.dir\Debug\lastbuild.timestamp".
21>CustomBuild:
21>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
21>ClCompile:
21>  BranchFolding.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  PPLexerChange.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  PPMacroExpansion.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  PTHLexer.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  Pragma.cpp
21>BranchFolding.cpp(410): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
21>          with
21>          [
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>BranchFolding.cpp(705): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
21>          with
21>          [
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>BranchFolding.cpp(1144): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
21>          with
21>          [
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>  CodePlacementOpt.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  Preprocessor.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  PreprocessorLexer.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  TokenConcatenation.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  TokenLexer.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>CodePlacementOpt.cpp(181): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
21>          with
21>          [
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>CodePlacementOpt.cpp(183): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
21>          with
21>          [
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>  DeadMachineInstructionElim.cpp
20>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
20>  Generating Code...
20>
20>Build FAILED.
20>
20>Time Elapsed 00:00:09.18
22>------ Build started: Project: clangFrontend, Configuration: Debug Win32 ------
22>Build started 7/10/2009 7:49:05 AM.
22>IsProjectFileNewer:
22>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
22>_PrepareForBuild:
22>  Touching "clangFrontend.dir\Debug\lastbuild.timestamp".
22>CustomBuild:
22>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
22>ClCompile:
22>  ASTConsumers.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  ASTUnit.cpp
21>  DwarfEHPrepare.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  AnalysisConsumer.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  Backend.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  CacheTokens.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>  ELFCodeEmitter.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  DeclXML.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  DependencyFile.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  DiagChecker.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  DocumentXML.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  FixItRewriter.cpp
21>  ELFWriter.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  GeneratePCH.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  HTMLDiagnostics.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  HTMLPrint.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>  GCStrategy.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  InitHeaderSearch.cpp
22>  InitPreprocessor.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  ManagerRegistry.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  PCHReader.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  PCHReaderDecl.cpp
21>  IfConversion.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  PCHReaderStmt.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  PCHWriter.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  Generating Code...
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
22>  Compiling...
22>  PCHWriterDecl.cpp
21>  IntrinsicLowering.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  PCHWriterStmt.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  PlistDiagnostics.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  PrintPreprocessedOutput.cpp
21>  LLVMTargetMachine.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  RewriteBlocks.cpp
21>  LazyLiveness.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  RewriteMacros.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  RewriteObjC.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  RewriteTest.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  StmtXML.cpp
21>  LiveInterval.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  TextDiagnosticBuffer.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  TextDiagnosticPrinter.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  TypeXML.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
21>  LiveIntervalAnalysis.cpp
22>  Warnings.cpp
22>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
22>  Generating Code...
22>
22>Build FAILED.
22>
22>Time Elapsed 00:00:16.90
23>------ Build started: Project: LLVMX86AsmParser, Configuration: Debug Win32 ------
23>Build started 7/10/2009 7:49:23 AM.
23>IsProjectFileNewer:
23>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
23>_PrepareForBuild:
23>  Touching "LLVMX86AsmParser.dir\Debug\lastbuild.timestamp".
21>LiveIntervalAnalysis.cpp(1480): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineRegisterInfo::def_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineRegisterInfo::def_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineRegisterInfo::def_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineRegisterInfo::def_iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineRegisterInfo::def_iterator)'
21>LiveIntervalAnalysis.cpp(1493): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineRegisterInfo::def_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineRegisterInfo::def_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineRegisterInfo::def_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineRegisterInfo::def_iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineRegisterInfo::def_iterator)'
21>  LiveStackAnalysis.cpp
21>  LiveVariables.cpp
21>  LowerSubregs.cpp
21>  MachOCodeEmitter.cpp
21>  MachOWriter.cpp
21>  MachineBasicBlock.cpp
21>MachineBasicBlock.cpp(289): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineFunction::const_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineFunction::const_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineFunction::const_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineFunction::const_iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineFunction::const_iterator)'
21>MachineBasicBlock.cpp(346): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::ilist_iterator<llvm::MachineBasicBlock>,
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
21>          with
21>          [
21>              NodeTy=llvm::MachineBasicBlock
21>          ]
21>  MachineDominators.cpp
21>  Generating Code...
21>  Compiling...
21>  MachineFunction.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>  MachineFunctionPass.cpp
21>  MachineInstr.cpp
21>  MachineLICM.cpp
21>  MachineLoopInfo.cpp
21>  MachineModuleInfo.cpp
21>  MachineRegisterInfo.cpp
21>  MachineSink.cpp
21>  MachineVerifier.cpp
21>  ObjectCodeEmitter.cpp
21>  PHIElimination.cpp
21>PHIElimination.cpp(352): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>  PostRASchedulerList.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>  PreAllocSplitting.cpp
21>  PrologEpilogInserter.cpp
21>PrologEpilogInserter.cpp(685): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>  PseudoSourceValue.cpp
21>  RegAllocLinearScan.cpp
21>c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory(205): error C2248: 'llvm::EquivalenceClasses<ElemTy>::ECValue::ECValue' : cannot access private member declared in class 'llvm::EquivalenceClasses<ElemTy>::ECValue'
21>          with
21>          [
21>              ElemTy=const llvm::TargetRegisterClass *
21>          ]
21>          C:\Temp\llvm\include\llvm/ADT/EquivalenceClasses.h(71) : see declaration of 'llvm::EquivalenceClasses<ElemTy>::ECValue::ECValue'
21>          with
21>          [
21>              ElemTy=const llvm::TargetRegisterClass *
21>          ]
21>          C:\Temp\llvm\include\llvm/ADT/EquivalenceClasses.h(65) : see declaration of 'llvm::EquivalenceClasses<ElemTy>::ECValue'
21>          with
21>          [
21>              ElemTy=const llvm::TargetRegisterClass *
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory(279) : see reference to function template instantiation 'void std::allocator<_Ty>::construct<const _Ty2&>(llvm::EquivalenceClasses<ElemTy>::ECValue *,_Other)' being compiled
21>          with
21>          [
21>              _Ty=llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue,
21>              _Ty2=const llvm::TargetRegisterClass *,
21>              ElemTy=const llvm::TargetRegisterClass *,
21>              _Other=const llvm::TargetRegisterClass *const &
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree(612) : see reference to function template instantiation 'void std::_Cons_val<std::allocator<_Ty>,llvm::EquivalenceClasses<ElemTy>::ECValue,ElemTy>(_Alloc &,_Ty1 *,const _Ty2 &)' being compiled
21>          with
21>          [
21>              _Ty=llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue,
21>              ElemTy=const llvm::TargetRegisterClass *,
21>              _Alloc=std::allocator<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,
21>              _Ty1=llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue,
21>              _Ty2=const llvm::TargetRegisterClass *
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree(775) : see reference to function template instantiation 'std::_Tree_nod<_Traits>::_Node *std::_Tree_val<_Traits>::_Buynode<const ElemTy&>(_Valty)' being compiled
21>          with
21>          [
21>              _Traits=std::_Tset_traits<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue,std::less<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,std::allocator<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,false>,
21>              ElemTy=const llvm::TargetRegisterClass *,
21>              _Valty=const llvm::TargetRegisterClass *const &
21>          ]
21>          C:\Temp\llvm\include\llvm/ADT/EquivalenceClasses.h(193) : see reference to function template instantiation 'std::pair<_Ty1,_Ty2> std::_Tree<_Traits>::insert<const ElemTy&>(_Valty)' being compiled
21>          with
21>          [
21>              _Ty1=std::_Tree_iterator<std::_Tree_val<std::_Tset_traits<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue,std::less<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,std::allocator<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,false>>>,
21>              _Ty2=bool,
21>              _Traits=std::_Tset_traits<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue,std::less<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,std::allocator<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,false>,
21>              ElemTy=const llvm::TargetRegisterClass *,
21>              _Valty=const llvm::TargetRegisterClass *const &
21>          ]
21>          C:\Temp\llvm\include\llvm/ADT/EquivalenceClasses.h(192) : while compiling class template member function 'std::_Tree_const_iterator<_Mytree> llvm::EquivalenceClasses<ElemTy>::insert(const ElemTy &)'
21>          with
21>          [
21>              _Mytree=std::_Tree_val<std::_Tset_traits<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue,std::less<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,std::allocator<llvm::EquivalenceClasses<const llvm::TargetRegisterClass *>::ECValue>,false>>,
21>              ElemTy=const llvm::TargetRegisterClass *
21>          ]
21>          RegAllocLinearScan.cpp(83) : see reference to class template instantiation 'llvm::EquivalenceClasses<ElemTy>' being compiled
21>          with
21>          [
21>              ElemTy=const llvm::TargetRegisterClass *
21>          ]
21>  RegAllocLocal.cpp
21>  RegAllocPBQP.cpp
21>  RegisterCoalescer.cpp
21>  RegisterScavenging.cpp
21>RegisterScavenging.cpp(131): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>  Generating Code...
21>  Compiling...
21>  ScheduleDAG.cpp
21>  ScheduleDAGEmit.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>  ScheduleDAGInstrs.cpp
21>  ScheduleDAGPrinter.cpp
21>  ShadowStackGC.cpp
21>  ShrinkWrapping.cpp
21>  SimpleRegisterCoalescing.cpp
21>SimpleRegisterCoalescing.cpp(708): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::ilist_iterator<llvm::MachineInstr>,
21>              NodeTy=llvm::MachineInstr
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::ilist_iterator<llvm::MachineInstr>,
21>              NodeTy=llvm::MachineInstr
21>          ]
21>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
21>          with
21>          [
21>              NodeTy=llvm::MachineInstr
21>          ]
21>SimpleRegisterCoalescing.cpp(2717): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::ilist_iterator<llvm::MachineInstr>,
21>              NodeTy=llvm::MachineInstr
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::ilist_iterator<llvm::MachineInstr>,
21>              NodeTy=llvm::MachineInstr
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>  SjLjEHPrepare.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>  Spiller.cpp
21>  StackProtector.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>  StackSlotColoring.cpp
21>StackSlotColoring.cpp(670): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>  StrongPHIElimination.cpp
21>  TwoAddressInstructionPass.cpp
21>TwoAddressInstructionPass.cpp(214): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>TwoAddressInstructionPass.cpp(415): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineRegisterInfo::def_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineRegisterInfo::def_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineRegisterInfo::def_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineRegisterInfo::def_iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineRegisterInfo::def_iterator)'
21>TwoAddressInstructionPass.cpp(646): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>TwoAddressInstructionPass.cpp(931): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>  UnreachableBlockElim.cpp
21>  VirtRegMap.cpp
21>  VirtRegRewriter.cpp
21>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::SDNode::use_iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::SDNode::use_iterator
21>          ]
21>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
21>VirtRegRewriter.cpp(722): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<std::_Tree_iterator<_Mytree>>(ItTy)'
21>          with
21>          [
21>              ItTy=std::_Tree_iterator<std::_Tree_val<std::_Tmap_traits<unsigned int,int,std::less<unsigned int>,std::allocator<std::pair<const unsigned int,int>>,true>>>,
21>              _Mytree=std::_Tree_val<std::_Tmap_traits<unsigned int,int,std::less<unsigned int>,std::allocator<std::pair<const unsigned int,int>>,true>>
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<std::_Tree_iterator<_Mytree>>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=std::_Tree_iterator<std::_Tree_val<std::_Tmap_traits<unsigned int,int,std::less<unsigned int>,std::allocator<std::pair<const unsigned int,int>>,true>>>,
21>              _Mytree=std::_Tree_val<std::_Tmap_traits<unsigned int,int,std::less<unsigned int>,std::allocator<std::pair<const unsigned int,int>>,true>>
21>          ]
21>          while trying to match the argument list '(std::_Tree_iterator<_Mytree>)'
21>          with
21>          [
21>              _Mytree=std::_Tree_val<std::_Tmap_traits<unsigned int,int,std::less<unsigned int>,std::allocator<std::pair<const unsigned int,int>>,true>>
21>          ]
21>VirtRegRewriter.cpp(1104): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1157): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1434): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1435): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1470): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1571): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1578): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1602): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1612): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1729): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1730): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(1735): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(2206): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>VirtRegRewriter.cpp(2322): error C2668: 'llvm::next' : ambiguous call to overloaded function
21>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::MachineBasicBlock::iterator>(ItTy)'
21>          with
21>          [
21>              ItTy=llvm::MachineBasicBlock::iterator
21>          ]
21>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::MachineBasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
21>          with
21>          [
21>              _InIt=llvm::MachineBasicBlock::iterator
21>          ]
21>          while trying to match the argument list '(llvm::MachineBasicBlock::iterator)'
21>  Generating Code...
21>
21>Build FAILED.
21>
21>Time Elapsed 00:01:51.08
14>CustomBuild:
13>CustomBuild:
13>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
14>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
24>------ Build started: Project: clangCodeGen, Configuration: Debug Win32 ------
24>Build started 7/10/2009 7:50:51 AM.
24>IsProjectFileNewer:
24>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
24>_PrepareForBuild:
24>  Touching "clangCodeGen.dir\Debug\lastbuild.timestamp".
24>CustomBuild:
24>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
14>ClCompile:
14>  X86ATTInstPrinter.cpp
13>ClCompile:
13>  X86TargetInfo.cpp
24>ClCompile:
24>  CGBlocks.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGBuiltin.cpp
14>  X86AsmPrinter.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGCXX.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGCXXClass.cpp
13>Lib:
13>  LLVMX86Info.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMX86Info.lib
23>CustomBuild:
23>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
23>ClCompile:
23>  X86AsmParser.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGCXXExpr.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGCXXTemp.cpp
14>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
14>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
14>          with
14>          [
14>              ItTy=llvm::SDNode::use_iterator
14>          ]
14>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
14>          with
14>          [
14>              _InIt=llvm::SDNode::use_iterator
14>          ]
14>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGCall.cpp
23>Lib:
23>  LLVMX86AsmParser.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMX86AsmParser.lib
14>  X86IntelInstPrinter.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGDebugInfo.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGDecl.cpp
14>  X86MCInstLower.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGExpr.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGExprAgg.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGExprComplex.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGExprConstant.cpp
14>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
14>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
14>          with
14>          [
14>              ItTy=llvm::SDNode::use_iterator
14>          ]
14>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
14>          with
14>          [
14>              _InIt=llvm::SDNode::use_iterator
14>          ]
14>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
14>  Generating Code...
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGExprScalar.cpp
14>
14>Build FAILED.
14>
14>Time Elapsed 00:02:43.05
25>------ Build started: Project: clangBasic, Configuration: Debug Win32 ------
25>Build started 7/10/2009 7:50:57 AM.
25>_PrepareForBuild:
25>  Touching "clangBasic.dir\Debug\lastbuild.timestamp".
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGObjC.cpp
25>CustomBuild:
25>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
25>ClCompile:
25>  Builtins.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGObjCGNU.cpp
25>  Diagnostic.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGObjCMac.cpp
25>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
25>  FileManager.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGRecordLayoutBuilder.cpp
25>  IdentifierTable.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CGStmt.cpp
25>  SourceLocation.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CodeGenFunction.cpp
25>  SourceManager.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  Generating Code...
24>  Compiling...
24>  CodeGenModule.cpp
25>  TargetInfo.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  CodeGenTypes.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  Mangle.cpp
25>  Targets.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  ModuleBuilder.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  TargetABIInfo.cpp
24>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
24>  Generating Code...
25>  TokenKinds.cpp
25>  Generating Code...
24>
24>Build FAILED.
24>
24>Time Elapsed 00:00:11.87
26>------ Build started: Project: clangAnalysis, Configuration: Debug Win32 ------
26>Build started 7/10/2009 7:51:03 AM.
26>IsProjectFileNewer:
26>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
26>_PrepareForBuild:
26>  Touching "clangAnalysis.dir\Debug\lastbuild.timestamp".
26>CustomBuild:
26>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
26>ClCompile:
26>  AnalysisContext.cpp
25>
25>Build FAILED.
25>
25>Time Elapsed 00:00:06.63
13>_AfterBuild:
13>  Touching "LLVMX86Info.dir\Debug\LastSuccessfulBuild.timestamp".
13>
13>Build succeeded.
13>
13>Time Elapsed 00:02:50.00
23>_AfterBuild:
23>  Touching "LLVMX86AsmParser.dir\Debug\LastSuccessfulBuild.timestamp".
23>
23>Build succeeded.
23>
23>Time Elapsed 00:01:40.98
27>------ Build started: Project: clangAST, Configuration: Debug Win32 ------
27>Build started 7/10/2009 7:51:04 AM.
27>_PrepareForBuild:
27>  Touching "clangAST.dir\Debug\lastbuild.timestamp".
28>------ Build started: Project: LLVMTransformUtils, Configuration: Debug Win32 ------
28>Build started 7/10/2009 7:51:04 AM.
28>IsProjectFileNewer:
28>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
28>_PrepareForBuild:
28>  Touching "LLVMTransformUtils.dir\Debug\lastbuild.timestamp".
28>CustomBuild:
28>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
28>ClCompile:
28>  AddrModeMatcher.cpp
29>------ Build started: Project: LLVMTarget, Configuration: Debug Win32 ------
29>Build started 7/10/2009 7:51:04 AM.
29>IsProjectFileNewer:
29>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
29>_PrepareForBuild:
29>  Touching "LLVMTarget.dir\Debug\lastbuild.timestamp".
29>CustomBuild:
29>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  AnalysisManager.cpp
29>ClCompile:
29>  Target.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  BasicConstraintManager.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  BasicObjCFoundationChecks.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  BasicStore.cpp
29>  TargetData.cpp
28>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
28>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
28>          with
28>          [
28>              ItTy=llvm::SDNode::use_iterator
28>          ]
28>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
28>          with
28>          [
28>              _InIt=llvm::SDNode::use_iterator
28>          ]
28>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  BasicValueFactory.cpp
28>  BasicBlockUtils.cpp
29>  TargetInstrInfo.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  BugReporter.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  BugReporterVisitors.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CFG.cpp
29>  TargetLoweringObjectFile.cpp
28>  BasicInliner.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CFRefCount.cpp
29>  TargetRegisterInfo.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CallGraph.cpp
28>  BreakCriticalEdges.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CallInliner.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CheckDeadStores.cpp
29>  Generating Code...
28>  CloneFunction.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CheckNSError.cpp
29>Lib:
29>  LLVMTarget.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMTarget.lib
29>_AfterBuild:
29>  Touching "LLVMTarget.dir\Debug\LastSuccessfulBuild.timestamp".
29>
29>Build succeeded.
29>
29>Time Elapsed 00:00:06.93
30>------ Build started: Project: LLVMSelectionDAG, Configuration: Debug Win32 ------
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
30>Build started 7/10/2009 7:51:11 AM.
30>_PrepareForBuild:
30>  Touching "LLVMSelectionDAG.dir\Debug\lastbuild.timestamp".
26>  CheckObjCDealloc.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CheckObjCInstMethSignature.cpp
28>  CloneLoop.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CheckObjCUnusedIVars.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  CheckSecuritySyntaxOnly.cpp
28>  CloneModule.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  Environment.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  ExplodedGraph.cpp
28>  CodeExtractor.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  Generating Code...
26>  Compiling...
26>  GRCoreEngine.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  GRExprEngine.cpp
28>  DemoteRegToStack.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  GRExprEngineInternalChecks.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  GRState.cpp
28>  InlineCost.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  LiveVariables.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  MemRegion.cpp
28>  InlineFunction.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  PathDiagnostic.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  RangeConstraintManager.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  RegionStore.cpp
28>  InstructionNamer.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  SVals.cpp
28>  LCSSA.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  SValuator.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  SimpleConstraintManager.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  SimpleSValuator.cpp
28>  Local.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  Store.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  SymbolManager.cpp
28>  LoopSimplify.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  UninitializedValues.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  ValueManager.cpp
28>  LowerAllocations.cpp
26>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
26>  Generating Code...
26>
26>Build FAILED.
26>
26>Time Elapsed 00:00:19.62
30>CustomBuild:
30>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
28>  LowerInvoke.cpp
30>ClCompile:
30>  CallingConvLower.cpp
31>------ Build started: Project: LLVMScalarOpts, Configuration: Debug Win32 ------
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
28>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
28>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
28>          with
28>          [
28>              ItTy=llvm::SDNode::use_iterator
28>          ]
28>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
28>          with
28>          [
28>              _InIt=llvm::SDNode::use_iterator
28>          ]
28>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  DAGCombiner.cpp
28>LowerInvoke.cpp(156): error C2039: 'setjmp' : is not a member of 'llvm::Intrinsic'
28>LowerInvoke.cpp(156): error C2065: 'setjmp' : undeclared identifier
28>  LowerSwitch.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
28>LowerSwitch.cpp(248): error C2668: 'llvm::next' : ambiguous call to overloaded function
28>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<std::_Vector_iterator<_Myvec>>(ItTy)'
28>          with
28>          [
28>              ItTy=std::_Vector_iterator<std::_Vector_val<`anonymous-namespace'::LowerSwitch::CaseRange,std::allocator<`anonymous-namespace'::LowerSwitch::CaseRange>>>,
28>              _Myvec=std::_Vector_val<`anonymous-namespace'::LowerSwitch::CaseRange,std::allocator<`anonymous-namespace'::LowerSwitch::CaseRange>>
28>          ]
28>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<std::_Vector_iterator<_Myvec>>(_InIt,__w64 int)' [found using argument-dependent lookup]
28>          with
28>          [
28>              _InIt=std::_Vector_iterator<std::_Vector_val<`anonymous-namespace'::LowerSwitch::CaseRange,std::allocator<`anonymous-namespace'::LowerSwitch::CaseRange>>>,
28>              _Myvec=std::_Vector_val<`anonymous-namespace'::LowerSwitch::CaseRange,std::allocator<`anonymous-namespace'::LowerSwitch::CaseRange>>
28>          ]
28>          while trying to match the argument list '(std::_Vector_iterator<_Myvec>)'
28>          with
28>          [
28>              _Myvec=std::_Vector_val<`anonymous-namespace'::LowerSwitch::CaseRange,std::allocator<`anonymous-namespace'::LowerSwitch::CaseRange>>
28>          ]
28>  Mem2Reg.cpp
30>  FastISel.cpp
28>  PromoteMemoryToRegister.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>FastISel.cpp(608): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::ilist_iterator<llvm::MachineBasicBlock>,
30>              NodeTy=llvm::MachineBasicBlock
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::ilist_iterator<llvm::MachineBasicBlock>,
30>              NodeTy=llvm::MachineBasicBlock
30>          ]
30>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
30>          with
30>          [
30>              NodeTy=llvm::MachineBasicBlock
30>          ]
30>  LegalizeDAG.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
28>  Generating Code...
30>LegalizeDAG.cpp(234): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SelectionDAG::allnodes_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SelectionDAG::allnodes_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SelectionDAG::allnodes_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SelectionDAG::allnodes_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SelectionDAG::allnodes_iterator)'
30>  LegalizeFloatTypes.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  LegalizeIntegerTypes.cpp
28>  Compiling...
28>  SSI.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  LegalizeTypes.cpp
28>  SimplifyCFG.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  LegalizeTypesGeneric.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  LegalizeVectorOps.cpp
28>c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(283): error C2440: 'return' : cannot convert from 'const llvm::SuccIterator<Term_,BB_>' to 'llvm::succ_iterator &'
28>          with
28>          [
28>              Term_=llvm::TerminatorInst *,
28>              BB_=llvm::BasicBlock
28>          ]
28>          Conversion loses qualifiers
28>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\algorithm(74) : see reference to function template instantiation '_Iter &std::_Rechecked<_InIt,_InIt>(_Iter &,_UIter)' being compiled
28>          with
28>          [
28>              _Iter=llvm::succ_iterator,
28>              _InIt=llvm::succ_iterator,
28>              _UIter=llvm::succ_iterator
28>          ]
28>          SimplifyCFG.cpp(71) : see reference to function template instantiation '_InIt std::find<llvm::succ_iterator,llvm::BasicBlock*>(_InIt,_InIt,const _Ty &)' being compiled
28>          with
28>          [
28>              _InIt=llvm::succ_iterator,
28>              _Ty=llvm::BasicBlock *
28>          ]
28>  UnifyFunctionExitNodes.cpp
28>  UnrollLoop.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>LegalizeVectorOps.cpp(85): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SelectionDAG::allnodes_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SelectionDAG::allnodes_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SelectionDAG::allnodes_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SelectionDAG::allnodes_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SelectionDAG::allnodes_iterator)'
30>  LegalizeVectorTypes.cpp
28>  ValueMapper.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  ScheduleDAGFast.cpp
28>  Generating Code...
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
28>
28>Build FAILED.
28>
28>Time Elapsed 00:00:34.90
31>Build started 7/10/2009 7:51:39 AM.
31>_PrepareForBuild:
31>  Touching "LLVMScalarOpts.dir\Debug\lastbuild.timestamp".
31>CustomBuild:
31>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
30>  ScheduleDAGList.cpp
31>ClCompile:
31>  ADCE.cpp
32>------ Build started: Project: LLVMCore, Configuration: Debug Win32 ------
32>Build started 7/10/2009 7:51:39 AM.
32>IsProjectFileNewer:
32>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
32>_PrepareForBuild:
32>  Touching "LLVMCore.dir\Debug\lastbuild.timestamp".
32>CustomBuild:
32>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
32>ClCompile:
32>  AsmWriter.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  ScheduleDAGRRList.cpp
31>  BasicBlockPlacement.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
31>  CodeGenLICM.cpp
30>  ScheduleDAGSDNodes.cpp
32>  Attributes.cpp
32>  AutoUpgrade.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
31>  CodeGenPrepare.cpp
30>  ScheduleDAGSDNodesEmit.cpp
32>  BasicBlock.cpp
31>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
31>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
31>          with
31>          [
31>              ItTy=llvm::SDNode::use_iterator
31>          ]
31>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
31>          with
31>          [
31>              _InIt=llvm::SDNode::use_iterator
31>          ]
31>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
31>  CondPropagate.cpp
32>BasicBlock.cpp(247): error C2668: 'llvm::next' : ambiguous call to overloaded function
32>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
32>          with
32>          [
32>              ItTy=llvm::ilist_iterator<llvm::BasicBlock>,
32>              NodeTy=llvm::BasicBlock
32>          ]
32>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
32>          with
32>          [
32>              _InIt=llvm::ilist_iterator<llvm::BasicBlock>,
32>              NodeTy=llvm::BasicBlock
32>          ]
32>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
32>          with
32>          [
32>              NodeTy=llvm::BasicBlock
32>          ]
32>BasicBlock.cpp(248): error C2228: left of '.getNodePtrUnchecked' must have class/struct/union
32>  ConstantFold.cpp
30>  SelectionDAG.cpp
31>  ConstantProp.cpp
32>  Constants.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  SelectionDAGBuild.cpp
31>  DCE.cpp
31>  DeadStoreElimination.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  SelectionDAGISel.cpp
31>  GVN.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
32>  Core.cpp
31>  IndVarSimplify.cpp
30>SelectionDAGISel.cpp(790): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::BasicBlock::iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::BasicBlock::iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::BasicBlock::iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::BasicBlock::iterator
30>          ]
30>          while trying to match the argument list '(llvm::BasicBlock::iterator)'
30>  SelectionDAGPrinter.cpp
32>  Dominators.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
30>  TargetLowering.cpp
31>  InstructionCombining.cpp
32>  Function.cpp
30>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
30>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
30>          with
30>          [
30>              ItTy=llvm::SDNode::use_iterator
30>          ]
30>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
30>          with
30>          [
30>              _InIt=llvm::SDNode::use_iterator
30>          ]
30>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
32>  Globals.cpp
30>  Generating Code...
31>InstructionCombining.cpp(12843): error C2668: 'llvm::next' : ambiguous call to overloaded function
31>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::pred_iterator>(ItTy)'
31>          with
31>          [
31>              ItTy=llvm::pred_iterator
31>          ]
31>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::pred_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
31>          with
31>          [
31>              _InIt=llvm::pred_iterator
31>          ]
31>          while trying to match the argument list '(llvm::pred_iterator)'
31>  JumpThreading.cpp
32>  InlineAsm.cpp
30>
30>Build FAILED.
30>
30>Time Elapsed 00:00:43.98
32>  Instruction.cpp
33>------ Build started: Project: LLVMipo, Configuration: Debug Win32 ------
33>Build started 7/10/2009 7:51:55 AM.
33>IsProjectFileNewer:
33>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
33>_PrepareForBuild:
33>  Touching "LLVMipo.dir\Debug\lastbuild.timestamp".
33>CustomBuild:
33>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
33>ClCompile:
33>  ArgumentPromotion.cpp
31>  LICM.cpp
32>  Instructions.cpp
31>  LoopDeletion.cpp
33>  ConstantMerge.cpp
33>  DeadArgumentElimination.cpp
31>  LoopIndexSplit.cpp
33>  DeadTypeElimination.cpp
31>  LoopRotation.cpp
32>  IntrinsicInst.cpp
33>  ExtractGV.cpp
32>  LLVMContext.cpp
33>  FunctionAttrs.cpp
31>  LoopStrengthReduce.cpp
31>C:\Temp\llvm\include\llvm/CodeGen/SelectionDAGNodes.h(1114): error C2668: 'llvm::next' : ambiguous call to overloaded function
31>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::SDNode::use_iterator>(ItTy)'
31>          with
31>          [
31>              ItTy=llvm::SDNode::use_iterator
31>          ]
31>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::SDNode::use_iterator>(_InIt,__w64 int)' [found using argument-dependent lookup]
31>          with
31>          [
31>              _InIt=llvm::SDNode::use_iterator
31>          ]
31>          while trying to match the argument list '(llvm::SDNode::use_iterator)'
33>  GlobalDCE.cpp
31>  LoopUnroll.cpp
33>  GlobalOpt.cpp
32>  LeakDetector.cpp
31>  LoopUnswitch.cpp
33>  IPConstantPropagation.cpp
33>  IPO.cpp
32>  Metadata.cpp
31>  MemCpyOptimizer.cpp
33>  IndMemRemoval.cpp
31>  Generating Code...
33>  InlineAlways.cpp
32>  Module.cpp
33>  InlineSimple.cpp
32>  ModuleProvider.cpp
31>  Compiling...
31>  Reassociate.cpp
33>  Inliner.cpp
32>  Pass.cpp
31>  Reg2Mem.cpp
32>  Generating Code...
33>  Internalize.cpp
31>  SCCP.cpp
33>  LoopExtractor.cpp
31>  Scalar.cpp
33>  LowerSetJmp.cpp
31>  ScalarReplAggregates.cpp
33>  MergeFunctions.cpp
32>  Compiling...
32>  PassManager.cpp
31>  SimplifyCFGPass.cpp
33>  PartialInlining.cpp
31>  SimplifyHalfPowrLibCalls.cpp
32>  PrintModulePass.cpp
33>  PartialSpecialization.cpp
31>SimplifyHalfPowrLibCalls.cpp(91): error C2668: 'llvm::next' : ambiguous call to overloaded function
31>          C:\Temp\llvm\include\llvm/ADT/STLExtras.h(150): could be 'ItTy llvm::next<llvm::ilist_iterator<NodeTy>>(ItTy)'
31>          with
31>          [
31>              ItTy=llvm::ilist_iterator<llvm::Instruction>,
31>              NodeTy=llvm::Instruction
31>          ]
31>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(1155): or       '_InIt std::next<llvm::ilist_iterator<NodeTy>>(_InIt,__w64 int)' [found using argument-dependent lookup]
31>          with
31>          [
31>              _InIt=llvm::ilist_iterator<llvm::Instruction>,
31>              NodeTy=llvm::Instruction
31>          ]
31>          while trying to match the argument list '(llvm::ilist_iterator<NodeTy>)'
31>          with
31>          [
31>              NodeTy=llvm::Instruction
31>          ]
31>  SimplifyLibCalls.cpp
32>  Type.cpp
33>  Generating Code...
31>  TailDuplication.cpp
31>  TailRecursionElimination.cpp
33>  Compiling...
33>  PruneEH.cpp
31>  Generating Code...
32>  TypeSymbolTable.cpp
32>  Value.cpp
33>  RaiseAllocations.cpp
33>  StripDeadPrototypes.cpp
31>
31>Build FAILED.
31>
31>Time Elapsed 00:00:49.29
34>------ Build started: Project: clangDriver, Configuration: Debug Win32 ------
34>Build started 7/10/2009 7:52:28 AM.
34>IsProjectFileNewer:
34>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
34>_PrepareForBuild:
34>  Touching "clangDriver.dir\Debug\lastbuild.timestamp".
34>CustomBuild:
34>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
34>ClCompile:
34>  Arg.cpp
33>  StripSymbols.cpp
32>  ValueSymbolTable.cpp
34>  ArgList.cpp
32>  ValueTypes.cpp
33>  StructRetPromotion.cpp
34>  Compilation.cpp
32>  Verifier.cpp
34>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
34>  Driver.cpp
34>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
34>  HostInfo.cpp
33>  Generating Code...
34>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
34>  OptTable.cpp
34>  Option.cpp
32>  Generating Code...
34>  ToolChain.cpp
33>Lib:
33>  LLVMipo.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMipo.lib
27>CustomBuild:
27>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
27>ClCompile:
27>  APValue.cpp
34>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
34>  ToolChains.cpp
27>  ASTConsumer.cpp
34>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
34>  Tools.cpp
27>  ASTContext.cpp
34>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
34>  Generating Code...
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  CXXInheritance.cpp
34>
34>Build FAILED.
34>
34>Time Elapsed 00:00:06.34
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  Decl.cpp
35>------ Build started: Project: clangIndex, Configuration: Debug Win32 ------
35>Build started 7/10/2009 7:52:35 AM.
35>IsProjectFileNewer:
35>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
35>_PrepareForBuild:
35>  Touching "clangIndex.dir\Debug\lastbuild.timestamp".
35>CustomBuild:
35>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
32>
32>Build FAILED.
32>
32>Time Elapsed 00:00:55.94
35>ClCompile:
35>  ASTLocation.cpp
36>------ Build started: Project: LLVMInstrumentation, Configuration: Debug Win32 ------
36>Build started 7/10/2009 7:52:35 AM.
36>IsProjectFileNewer:
36>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
36>_PrepareForBuild:
36>  Touching "LLVMInstrumentation.dir\Debug\lastbuild.timestamp".
36>CustomBuild:
36>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  DeclBase.cpp
36>ClCompile:
36>  BlockProfiling.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  Analyzer.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  DeclCXX.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  DeclReferenceMap.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  Entity.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  DeclGroup.cpp
36>  EdgeProfiling.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  GlobalSelector.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  DeclObjC.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  Indexer.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  DeclPrinter.cpp
36>  OptimalEdgeProfiling.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  Program.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  DeclTemplate.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  ResolveLocation.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  SelectorMap.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  DeclarationName.cpp
36>c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory(205): error C2248: 'llvm::EquivalenceClasses<ElemTy>::ECValue::ECValue' : cannot access private member declared in class 'llvm::EquivalenceClasses<ElemTy>::ECValue'
36>          with
36>          [
36>              ElemTy=const llvm::BasicBlock *
36>          ]
36>          C:\Temp\llvm\include\llvm/ADT/EquivalenceClasses.h(71) : see declaration of 'llvm::EquivalenceClasses<ElemTy>::ECValue::ECValue'
36>          with
36>          [
36>              ElemTy=const llvm::BasicBlock *
36>          ]
36>          C:\Temp\llvm\include\llvm/ADT/EquivalenceClasses.h(65) : see declaration of 'llvm::EquivalenceClasses<ElemTy>::ECValue'
36>          with
36>          [
36>              ElemTy=const llvm::BasicBlock *
36>          ]
36>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xmemory(279) : see reference to function template instantiation 'void std::allocator<_Ty>::construct<const _Ty2&>(llvm::EquivalenceClasses<ElemTy>::ECValue *,_Other)' being compiled
36>          with
36>          [
36>              _Ty=llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue,
36>              _Ty2=const llvm::BasicBlock *,
36>              ElemTy=const llvm::BasicBlock *,
36>              _Other=const llvm::BasicBlock *const &
36>          ]
36>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree(612) : see reference to function template instantiation 'void std::_Cons_val<std::allocator<_Ty>,llvm::EquivalenceClasses<ElemTy>::ECValue,ElemTy>(_Alloc &,_Ty1 *,const _Ty2 &)' being compiled
36>          with
36>          [
36>              _Ty=llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue,
36>              ElemTy=const llvm::BasicBlock *,
36>              _Alloc=std::allocator<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,
36>              _Ty1=llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue,
36>              _Ty2=const llvm::BasicBlock *
36>          ]
36>          c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xtree(775) : see reference to function template instantiation 'std::_Tree_nod<_Traits>::_Node *std::_Tree_val<_Traits>::_Buynode<const ElemTy&>(_Valty)' being compiled
36>          with
36>          [
36>              _Traits=std::_Tset_traits<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue,std::less<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,std::allocator<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,false>,
36>              ElemTy=const llvm::BasicBlock *,
36>              _Valty=const llvm::BasicBlock *const &
36>          ]
36>          C:\Temp\llvm\include\llvm/ADT/EquivalenceClasses.h(193) : see reference to function template instantiation 'std::pair<_Ty1,_Ty2> std::_Tree<_Traits>::insert<const ElemTy&>(_Valty)' being compiled
36>          with
36>          [
36>              _Ty1=std::_Tree_iterator<std::_Tree_val<std::_Tset_traits<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue,std::less<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,std::allocator<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,false>>>,
36>              _Ty2=bool,
36>              _Traits=std::_Tset_traits<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue,std::less<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,std::allocator<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,false>,
36>              ElemTy=const llvm::BasicBlock *,
36>              _Valty=const llvm::BasicBlock *const &
36>          ]
36>          C:\Temp\llvm\include\llvm/ADT/EquivalenceClasses.h(192) : while compiling class template member function 'std::_Tree_const_iterator<_Mytree> llvm::EquivalenceClasses<ElemTy>::insert(const ElemTy &)'
36>          with
36>          [
36>              _Mytree=std::_Tree_val<std::_Tset_traits<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue,std::less<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,std::allocator<llvm::EquivalenceClasses<const llvm::BasicBlock *>::ECValue>,false>>,
36>              ElemTy=const llvm::BasicBlock *
36>          ]
36>          c:\temp\llvm\lib\transforms\instrumentation\MaximumSpanningTree.h(61) : see reference to class template instantiation 'llvm::EquivalenceClasses<ElemTy>' being compiled
36>          with
36>          [
36>              ElemTy=const llvm::BasicBlock *
36>          ]
36>          c:\temp\llvm\lib\transforms\instrumentation\MaximumSpanningTree.h(54) : while compiling class template member function 'llvm::MaximumSpanningTree<T>::MaximumSpanningTree(std::vector<_Ty> &)'
36>          with
36>          [
36>              T=llvm::BasicBlock,
36>              _Ty=llvm::ProfileInfo::EdgeWeight
36>          ]
36>          OptimalEdgeProfiling.cpp(136) : see reference to class template instantiation 'llvm::MaximumSpanningTree<T>' being compiled
36>          with
36>          [
36>              T=llvm::BasicBlock
36>          ]
36>  ProfilingUtils.cpp
35>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
35>  Generating Code...
35>
35>Build FAILED.
35>
35>Time Elapsed 00:00:04.19
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  Expr.cpp
37>------ Build started: Project: LLVMInterpreter, Configuration: Debug Win32 ------
37>Build started 7/10/2009 7:52:39 AM.
37>IsProjectFileNewer:
37>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
37>_PrepareForBuild:
37>  Touching "LLVMInterpreter.dir\Debug\lastbuild.timestamp".
37>CustomBuild:
37>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
37>ClCompile:
37>  Execution.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  ExprCXX.cpp
36>  RSProfiling.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  ExprConstant.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  InheritViz.cpp
37>  ExternalFunctions.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  NestedNameSpecifier.cpp
36>  Generating Code...
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  ParentMap.cpp
36>
36>Build FAILED.
36>
36>Time Elapsed 00:00:06.94
38>------ Build started: Project: LLVMJIT, Configuration: Debug Win32 ------
38>Build started 7/10/2009 7:52:42 AM.
38>IsProjectFileNewer:
38>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
38>_PrepareForBuild:
38>  Touching "LLVMJIT.dir\Debug\lastbuild.timestamp".
38>CustomBuild:
38>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
38>ClCompile:
38>  JIT.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  RecordLayoutBuilder.cpp
37>  Interpreter.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  Stmt.cpp
37>  Generating Code...
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  Generating Code...
27>  Compiling...
27>  StmtDumper.cpp
37>Lib:
37>  LLVMInterpreter.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMInterpreter.lib
37>_AfterBuild:
37>  Touching "LLVMInterpreter.dir\Debug\LastSuccessfulBuild.timestamp".
37>
37>Build succeeded.
37>
37>Time Elapsed 00:00:04.91
39>------ Build started: Project: LLVMLinker, Configuration: Debug Win32 ------
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  StmtIterator.cpp
39>Build started 7/10/2009 7:52:44 AM.
39>IsProjectFileNewer:
39>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
39>_PrepareForBuild:
39>  Touching "LLVMLinker.dir\Debug\lastbuild.timestamp".
39>CustomBuild:
39>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
39>ClCompile:
39>  LinkArchives.cpp
38>  JITDebugRegisterer.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  StmtPrinter.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  StmtProfile.cpp
38>  JITDwarfEmitter.cpp
39>  LinkItems.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  StmtViz.cpp
39>  LinkModules.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  TemplateName.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  Type.cpp
38>  JITEmitter.cpp
39>  Linker.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  TypeLoc.cpp
27>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
27>  Generating Code...
39>  Generating Code...
27>
27>Build FAILED.
27>
27>Time Elapsed 00:01:45.18
33>_AfterBuild:
33>  Touching "LLVMipo.dir\Debug\LastSuccessfulBuild.timestamp".
33>
33>Build succeeded.
33>
33>Time Elapsed 00:00:53.52
40>------ Build started: Project: LLVMExecutionEngine, Configuration: Debug Win32 ------
41>------ Build started: Project: clang-cc, Configuration: Debug Win32 ------
40>Build started 7/10/2009 7:52:49 AM.
40>IsProjectFileNewer:
40>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
40>_PrepareForBuild:
40>  Touching "LLVMExecutionEngine.dir\Debug\lastbuild.timestamp".
40>CustomBuild:
41>Build started 7/10/2009 7:52:49 AM.
40>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
41>_PrepareForBuild:
41>  Touching "clang-cc.dir\Debug\lastbuild.timestamp".
40>ClCompile:
40>  ExecutionEngine.cpp
39>Lib:
39>  LLVMLinker.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMLinker.lib
39>_AfterBuild:
39>  Touching "LLVMLinker.dir\Debug\LastSuccessfulBuild.timestamp".
39>
39>Build succeeded.
39>
39>Time Elapsed 00:00:05.08
42>------ Build started: Project: LLVMAsmParser, Configuration: Debug Win32 ------
38>  OProfileJITEventListener.cpp
42>Build started 7/10/2009 7:52:51 AM.
42>IsProjectFileNewer:
42>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
42>_PrepareForBuild:
42>  Touching "LLVMAsmParser.dir\Debug\lastbuild.timestamp".
42>CustomBuild:
42>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
42>ClCompile:
42>  LLLexer.cpp
40>  ExecutionEngineBindings.cpp
42>  LLParser.cpp
38>  TargetSelect.cpp
40>  Generating Code...
40>Lib:
40>  LLVMExecutionEngine.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMExecutionEngine.lib
40>_AfterBuild:
40>  Touching "LLVMExecutionEngine.dir\Debug\LastSuccessfulBuild.timestamp".
40>
40>Build succeeded.
40>
40>Time Elapsed 00:00:03.98
38>  Generating Code...
43>------ Build started: Project: LLVMArchive, Configuration: Debug Win32 ------
43>Build started 7/10/2009 7:52:53 AM.
43>IsProjectFileNewer:
43>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
43>_PrepareForBuild:
43>  Touching "LLVMArchive.dir\Debug\lastbuild.timestamp".
43>CustomBuild:
43>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
43>ClCompile:
43>  Archive.cpp
42>  Parser.cpp
38>Lib:
38>  LLVMJIT.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMJIT.lib
38>_AfterBuild:
38>  Touching "LLVMJIT.dir\Debug\LastSuccessfulBuild.timestamp".
38>
38>Build succeeded.
38>
38>Time Elapsed 00:00:11.99
44>------ Build started: Project: Kaleidoscope-Ch7, Configuration: Debug Win32 ------
44>Build started 7/10/2009 7:52:54 AM.
44>_PrepareForBuild:
44>  Touching "Kaleidoscope-Ch7.dir\Debug\lastbuild.timestamp".
43>  ArchiveReader.cpp
42>  Generating Code...
44>CustomBuild:
44>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
44>ClCompile:
44>  toy.cpp
43>  Generating Code...
42>Lib:
42>  LLVMAsmParser.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMAsmParser.lib
42>_AfterBuild:
42>  Touching "LLVMAsmParser.dir\Debug\LastSuccessfulBuild.timestamp".
42>
42>Build succeeded.
42>
42>Time Elapsed 00:00:05.93
41>CustomBuild:
41>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
41>ClCompile:
41>  clang-cc.cpp
45>------ Build started: Project: Kaleidoscope-Ch6, Configuration: Debug Win32 ------
43>Lib:
43>  LLVMArchive.vcxproj -> C:\Temp\llvm\lib\Debug\LLVMArchive.lib
45>Build started 7/10/2009 7:52:57 AM.
43>_AfterBuild:
43>  Touching "LLVMArchive.dir\Debug\LastSuccessfulBuild.timestamp".
43>
43>Build succeeded.
43>
43>Time Elapsed 00:00:03.91
45>_PrepareForBuild:
45>  Touching "Kaleidoscope-Ch6.dir\Debug\lastbuild.timestamp".
45>CustomBuild:
45>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
45>ClCompile:
45>  toy.cpp
41>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
41>
41>Build FAILED.
41>
41>Time Elapsed 00:00:08.43
46>------ Build started: Project: index-test, Configuration: Debug Win32 ------
46>Build started 7/10/2009 7:52:57 AM.
46>IsProjectFileNewer:
46>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
46>_PrepareForBuild:
46>  Touching "index-test.dir\Debug\lastbuild.timestamp".
47>------ Build started: Project: llc, Configuration: Debug Win32 ------
47>Build started 7/10/2009 7:52:58 AM.
47>_PrepareForBuild:
47>  Touching "llc.dir\Debug\lastbuild.timestamp".
47>CustomBuild:
47>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
47>ClCompile:
47>  llc.cpp
44>ManifestResourceCompile:
44>  Skipping task because its outputs are up-to-date.
44>LINK : fatal error LNK1104: cannot open file '../../../lib/Debug/LLVMX86CodeGen.lib'
44>
44>Build FAILED.
44>
44>Time Elapsed 00:00:05.07
48>------ Build started: Project: opt, Configuration: Debug Win32 ------
48>Build started 7/10/2009 7:53:00 AM.
48>_PrepareForBuild:
48>  Touching "opt.dir\Debug\lastbuild.timestamp".
48>CustomBuild:
48>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
48>ClCompile:
48>  AnalysisWrappers.cpp
45>ManifestResourceCompile:
45>  Skipping task because its outputs are up-to-date.
45>LINK : fatal error LNK1104: cannot open file '../../../lib/Debug/LLVMX86CodeGen.lib'
45>
45>Build FAILED.
45>
45>Time Elapsed 00:00:03.65
49>------ Build started: Project: Kaleidoscope-Ch5, Configuration: Debug Win32 ------
49>Build started 7/10/2009 7:53:01 AM.
49>_PrepareForBuild:
49>  Touching "Kaleidoscope-Ch5.dir\Debug\lastbuild.timestamp".
49>CustomBuild:
49>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
49>ClCompile:
49>  toy.cpp
47>ManifestResourceCompile:
47>  Skipping task because its outputs are up-to-date.
47>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMX86AsmPrinter.lib'
47>
47>Build FAILED.
47>
47>Time Elapsed 00:00:03.66
50>------ Build started: Project: lli, Configuration: Debug Win32 ------
50>Build started 7/10/2009 7:53:02 AM.
50>_PrepareForBuild:
50>  Touching "lli.dir\Debug\lastbuild.timestamp".
50>CustomBuild:
50>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
50>ClCompile:
50>  lli.cpp
48>  GraphPrinters.cpp
49>ManifestResourceCompile:
49>  Skipping task because its outputs are up-to-date.
49>LINK : fatal error LNK1104: cannot open file '../../../lib/Debug/LLVMX86CodeGen.lib'
49>
49>Build FAILED.
49>
49>Time Elapsed 00:00:02.87
51>------ Build started: Project: clang, Configuration: Debug Win32 ------
51>Build started 7/10/2009 7:53:04 AM.
51>IsProjectFileNewer:
51>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
51>_PrepareForBuild:
51>  Touching "clang.dir\Debug\lastbuild.timestamp".
50>ManifestResourceCompile:
50>  Skipping task because its outputs are up-to-date.
50>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMX86CodeGen.lib'
50>
50>Build FAILED.
50>
50>Time Elapsed 00:00:02.89
52>------ Build started: Project: bugpoint, Configuration: Debug Win32 ------
51>CustomBuild:
51>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
52>Build started 7/10/2009 7:53:05 AM.
52>_PrepareForBuild:
52>  Touching "bugpoint.dir\Debug\lastbuild.timestamp".
51>ClCompile:
51>  driver.cpp
48>  PrintSCC.cpp
52>CustomBuild:
52>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
52>ClCompile:
52>  BugDriver.cpp
51>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
51>
51>Build FAILED.
51>
51>Time Elapsed 00:00:02.01
53>------ Build started: Project: llvm-ar, Configuration: Debug Win32 ------
53>Build started 7/10/2009 7:53:06 AM.
53>IsProjectFileNewer:
53>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
53>_PrepareForBuild:
53>  Touching "llvm-ar.dir\Debug\lastbuild.timestamp".
53>CustomBuild:
53>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
53>ClCompile:
53>  llvm-ar.cpp
48>  opt.cpp
52>  CrashDebugger.cpp
53>ManifestResourceCompile:
53>  Skipping task because its outputs are up-to-date.
53>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMCore.lib'
53>
53>Build FAILED.
53>
53>Time Elapsed 00:00:02.38
54>------ Build started: Project: Kaleidoscope-Ch4, Configuration: Debug Win32 ------
54>Build started 7/10/2009 7:53:09 AM.
54>_PrepareForBuild:
54>  Touching "Kaleidoscope-Ch4.dir\Debug\lastbuild.timestamp".
54>CustomBuild:
54>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
54>ClCompile:
54>  toy.cpp
52>  ExecutionDriver.cpp
48>  Generating Code...
52>  ExtractFunction.cpp
54>ManifestResourceCompile:
54>  Skipping task because its outputs are up-to-date.
48>ManifestResourceCompile:
48>  Skipping task because its outputs are up-to-date.
54>LINK : fatal error LNK1104: cannot open file '../../../lib/Debug/LLVMX86CodeGen.lib'
48>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMInstrumentation.lib'
54>
54>Build FAILED.
54>
54>Time Elapsed 00:00:02.55
48>
48>Build FAILED.
48>
48>Time Elapsed 00:00:11.51
46>CustomBuild:
46>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
55>------ Build started: Project: ModuleMaker, Configuration: Debug Win32 ------
55>Build started 7/10/2009 7:53:11 AM.
55>IsProjectFileNewer:
55>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
55>_PrepareForBuild:
55>  Touching "ModuleMaker.dir\Debug\lastbuild.timestamp".
46>ClCompile:
46>  index-test.cpp
55>CustomBuild:
55>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
56>------ Build started: Project: llvm-bcanalyzer, Configuration: Debug Win32 ------
52>  FindBugs.cpp
55>ClCompile:
55>  ModuleMaker.cpp
56>Build started 7/10/2009 7:53:12 AM.
56>IsProjectFileNewer:
56>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
56>_PrepareForBuild:
56>  Touching "llvm-bcanalyzer.dir\Debug\lastbuild.timestamp".
56>CustomBuild:
56>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
46>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
56>ClCompile:
56>  llvm-bcanalyzer.cpp
46>
46>Build FAILED.
46>
46>Time Elapsed 00:00:14.76
52>  Miscompilation.cpp
57>------ Build started: Project: llvm-dis, Configuration: Debug Win32 ------
57>Build started 7/10/2009 7:53:13 AM.
57>IsProjectFileNewer:
57>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
57>_PrepareForBuild:
57>  Touching "llvm-dis.dir\Debug\lastbuild.timestamp".
57>CustomBuild:
57>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
57>ClCompile:
57>  llvm-dis.cpp
55>ManifestResourceCompile:
55>  Skipping task because its outputs are up-to-date.
55>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMCore.lib'
52>  OptimizerDriver.cpp
55>
55>Build FAILED.
55>
55>Time Elapsed 00:00:02.34
58>------ Build started: Project: llvm-extract, Configuration: Debug Win32 ------
58>Build started 7/10/2009 7:53:14 AM.
58>IsProjectFileNewer:
58>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
58>_PrepareForBuild:
58>  Touching "llvm-extract.dir\Debug\lastbuild.timestamp".
56>ManifestResourceCompile:
56>  Skipping task because its outputs are up-to-date.
56>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMCore.lib'
56>
56>Build FAILED.
56>
56>Time Elapsed 00:00:02.33
59>------ Build started: Project: llvm-ld, Configuration: Debug Win32 ------
59>Build started 7/10/2009 7:53:14 AM.
59>_PrepareForBuild:
59>  Touching "llvm-ld.dir\Debug\lastbuild.timestamp".
52>  TestPasses.cpp
57>ManifestResourceCompile:
57>  Skipping task because its outputs are up-to-date.
57>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMCore.lib'
57>
57>Build FAILED.
57>
57>Time Elapsed 00:00:02.25
60>------ Build started: Project: llvm-link, Configuration: Debug Win32 ------
60>Build started 7/10/2009 7:53:15 AM.
60>IsProjectFileNewer:
60>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
60>_PrepareForBuild:
60>  Touching "llvm-link.dir\Debug\lastbuild.timestamp".
59>CustomBuild:
59>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
59>ClCompile:
59>  Optimize.cpp
52>  ToolRunner.cpp
52>  bugpoint.cpp
59>  llvm-ld.cpp
52>  Generating Code...
59>  Generating Code...
59>ManifestResourceCompile:
59>  Skipping task because its outputs are up-to-date.
59>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMScalarOpts.lib'
59>
59>Build FAILED.
59>
59>Time Elapsed 00:00:04.67
58>CustomBuild:
58>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
58>ClCompile:
58>  llvm-extract.cpp
61>------ Build started: Project: llvm-mc, Configuration: Debug Win32 ------
61>Build started 7/10/2009 7:53:19 AM.
61>_PrepareForBuild:
61>  Touching "llvm-mc.dir\Debug\lastbuild.timestamp".
52>ManifestResourceCompile:
52>  Skipping task because its outputs are up-to-date.
52>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMInstrumentation.lib'
52>
52>Build FAILED.
52>
52>Time Elapsed 00:00:14.88
61>CustomBuild:
61>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
61>ClCompile:
61>  llvm-mc.cpp
62>------ Build started: Project: llvm-nm, Configuration: Debug Win32 ------
62>Build started 7/10/2009 7:53:21 AM.
62>IsProjectFileNewer:
62>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
62>_PrepareForBuild:
62>  Touching "llvm-nm.dir\Debug\lastbuild.timestamp".
62>CustomBuild:
62>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
62>ClCompile:
62>  llvm-nm.cpp
58>ManifestResourceCompile:
58>  Skipping task because its outputs are up-to-date.
58>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMTransformUtils.lib'
58>
58>Build FAILED.
58>
58>Time Elapsed 00:00:07.64
61>  AsmLexer.cpp
63>------ Build started: Project: llvm-prof, Configuration: Debug Win32 ------
63>Build started 7/10/2009 7:53:22 AM.
63>IsProjectFileNewer:
63>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
63>_PrepareForBuild:
63>  Touching "llvm-prof.dir\Debug\lastbuild.timestamp".
63>CustomBuild:
63>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
63>ClCompile:
63>  llvm-prof.cpp
61>  AsmParser.cpp
62>ManifestResourceCompile:
62>  Skipping task because its outputs are up-to-date.
62>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMCore.lib'
62>
62>Build FAILED.
62>
62>Time Elapsed 00:00:02.06
64>------ Build started: Project: llvm-ranlib, Configuration: Debug Win32 ------
64>Build started 7/10/2009 7:53:23 AM.
64>IsProjectFileNewer:
64>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
64>_PrepareForBuild:
64>  Touching "llvm-ranlib.dir\Debug\lastbuild.timestamp".
61>  Generating Code...
64>CustomBuild:
64>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
64>ClCompile:
64>  llvm-ranlib.cpp
61>ManifestResourceCompile:
61>  Skipping task because its outputs are up-to-date.
61>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMX86AsmPrinter.lib'
61>
61>Build FAILED.
61>
61>Time Elapsed 00:00:03.78
65>------ Build started: Project: CIndex, Configuration: Debug Win32 ------
65>Build started 7/10/2009 7:53:23 AM.
65>IsProjectFileNewer:
65>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
65>_PrepareForBuild:
65>  Touching "CIndex.dir\Debug\lastbuild.timestamp".
65>CustomBuild:
65>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
65>ClCompile:
65>  CIndex.cpp
64>ManifestResourceCompile:
64>  Skipping task because its outputs are up-to-date.
65>C:\Temp\llvm\tools\clang\include\clang/Basic/Diagnostic.h(56): fatal error C1083: Cannot open include file: 'clang/Basic/DiagnosticCommonKinds.inc': No such file or directory
65>
65>Build FAILED.
65>
65>Time Elapsed 00:00:01.33
63>ManifestResourceCompile:
63>  Skipping task because its outputs are up-to-date.
64>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMCore.lib'
66>------ Build started: Project: BrainF, Configuration: Debug Win32 ------
64>
64>Build FAILED.
64>
64>Time Elapsed 00:00:02.10
66>Build started 7/10/2009 7:53:25 AM.
63>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMAnalysis.lib'
66>_PrepareForBuild:
66>  Touching "BrainF.dir\Debug\lastbuild.timestamp".
63>
63>Build FAILED.
63>
63>Time Elapsed 00:00:03.27
60>CustomBuild:
60>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
67>------ Build started: Project: Kaleidoscope-Ch3, Configuration: Debug Win32 ------
60>ClCompile:
60>  llvm-link.cpp
68>------ Build started: Project: HowToUseJIT, Configuration: Debug Win32 ------
68>Build started 7/10/2009 7:53:25 AM.
68>_PrepareForBuild:
68>  Touching "HowToUseJIT.dir\Debug\lastbuild.timestamp".
67>Build started 7/10/2009 7:53:25 AM.
67>IsProjectFileNewer:
67>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
67>_PrepareForBuild:
67>  Touching "Kaleidoscope-Ch3.dir\Debug\lastbuild.timestamp".
68>CustomBuild:
68>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
68>ClCompile:
68>  HowToUseJIT.cpp
67>CustomBuild:
67>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
67>ClCompile:
67>  toy.cpp
60>ManifestResourceCompile:
60>  Skipping task because its outputs are up-to-date.
60>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMCore.lib'
60>
60>Build FAILED.
60>
60>Time Elapsed 00:00:11.78
69>------ Build started: Project: llvm-as, Configuration: Debug Win32 ------
69>Build started 7/10/2009 7:53:27 AM.
69>IsProjectFileNewer:
69>Skipping target "IsProjectFileNewer" because all output files are up-to-date with respect to the input files.
69>_PrepareForBuild:
69>  Touching "llvm-as.dir\Debug\lastbuild.timestamp".
69>CustomBuild:
69>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
69>ClCompile:
69>  llvm-as.cpp
68>ManifestResourceCompile:
68>  Skipping task because its outputs are up-to-date.
67>ManifestResourceCompile:
67>  Skipping task because its outputs are up-to-date.
68>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMX86CodeGen.lib'
67>LINK : fatal error LNK1104: cannot open file '../../../lib/Debug/LLVMCore.lib'
67>
67>Build FAILED.
67>
67>Time Elapsed 00:00:02.55
68>
68>Build FAILED.
68>
68>Time Elapsed 00:00:02.60
70>------ Build started: Project: Fibonacci, Configuration: Debug Win32 ------
70>Build started 7/10/2009 7:53:28 AM.
70>_PrepareForBuild:
70>  Touching "Fibonacci.dir\Debug\lastbuild.timestamp".
71>------ Skipped Build: Project: clang-c++tests, Configuration: Debug Win32 ------
71>Project not selected to build for this solution configuration 
72>------ Skipped Build: Project: clang-test, Configuration: Debug Win32 ------
72>Project not selected to build for this solution configuration 
73>------ Skipped Build: Project: clang-test-Analysis, Configuration: Debug Win32 ------
73>Project not selected to build for this solution configuration 
74>------ Skipped Build: Project: clang-test-CXX, Configuration: Debug Win32 ------
74>Project not selected to build for this solution configuration 
75>------ Skipped Build: Project: clang-test-CodeCompletion, Configuration: Debug Win32 ------
75>Project not selected to build for this solution configuration 
76>------ Skipped Build: Project: clang-test-CodeGen, Configuration: Debug Win32 ------
76>Project not selected to build for this solution configuration 
77>------ Skipped Build: Project: clang-test-CodeGenCXX, Configuration: Debug Win32 ------
77>Project not selected to build for this solution configuration 
78>------ Skipped Build: Project: clang-test-CodeGenObjC, Configuration: Debug Win32 ------
78>Project not selected to build for this solution configuration 
79>------ Skipped Build: Project: clang-test-Coverage, Configuration: Debug Win32 ------
79>Project not selected to build for this solution configuration 
80>------ Skipped Build: Project: clang-test-Driver, Configuration: Debug Win32 ------
80>Project not selected to build for this solution configuration 
81>------ Skipped Build: Project: clang-test-FixIt, Configuration: Debug Win32 ------
81>Project not selected to build for this solution configuration 
82>------ Skipped Build: Project: clang-test-Frontend, Configuration: Debug Win32 ------
82>Project not selected to build for this solution configuration 
83>------ Skipped Build: Project: clang-test-Index, Configuration: Debug Win32 ------
83>Project not selected to build for this solution configuration 
84>------ Skipped Build: Project: clang-test-Lexer, Configuration: Debug Win32 ------
84>Project not selected to build for this solution configuration 
85>------ Skipped Build: Project: clang-test-Misc, Configuration: Debug Win32 ------
85>Project not selected to build for this solution configuration 
86>------ Skipped Build: Project: clang-test-PCH, Configuration: Debug Win32 ------
86>Project not selected to build for this solution configuration 
87>------ Skipped Build: Project: clang-test-Parser, Configuration: Debug Win32 ------
87>Project not selected to build for this solution configuration 
88>------ Skipped Build: Project: clang-test-Preprocessor, Configuration: Debug Win32 ------
88>Project not selected to build for this solution configuration 
89>------ Skipped Build: Project: clang-test-Rewriter, Configuration: Debug Win32 ------
89>Project not selected to build for this solution configuration 
90>------ Skipped Build: Project: clang-test-Sema, Configuration: Debug Win32 ------
90>Project not selected to build for this solution configuration 
91>------ Skipped Build: Project: clang-test-SemaCXX, Configuration: Debug Win32 ------
91>Project not selected to build for this solution configuration 
92>------ Skipped Build: Project: clang-test-SemaObjC, Configuration: Debug Win32 ------
92>Project not selected to build for this solution configuration 
93>------ Skipped Build: Project: clang-test-SemaObjCXX, Configuration: Debug Win32 ------
93>Project not selected to build for this solution configuration 
94>------ Skipped Build: Project: clang-test-SemaTemplate, Configuration: Debug Win32 ------
94>Project not selected to build for this solution configuration 
70>CustomBuild:
70>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
70>ClCompile:
70>  fibonacci.cpp
69>ManifestResourceCompile:
69>  Skipping task because its outputs are up-to-date.
69>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMCore.lib'
69>
69>Build FAILED.
69>
69>Time Elapsed 00:00:01.91
70>ManifestResourceCompile:
70>  Skipping task because its outputs are up-to-date.
70>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMX86CodeGen.lib'
70>
70>Build FAILED.
70>
70>Time Elapsed 00:00:01.78
66>CustomBuild:
66>Skipping target "CustomBuild" because all output files are up-to-date with respect to the input files.
66>ClCompile:
66>  BrainF.cpp
66>  BrainFDriver.cpp
66>  Generating Code...
66>ManifestResourceCompile:
66>  Skipping task because its outputs are up-to-date.
66>LINK : fatal error LNK1104: cannot open file '../../lib/Debug/LLVMX86CodeGen.lib'
66>
66>Build FAILED.
66>
66>Time Elapsed 00:00:08.18
95>------ Skipped Build: Project: INSTALL, Configuration: Debug Win32 ------
95>Project not selected to build for this solution configuration 
========== Build: 20 succeeded, 49 failed, 18 up-to-date, 26 skipped ==========

From lattner at apple.com  Tue Oct  6 17:44:19 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 6 Oct 2009 15:44:19 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
	<FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
Message-ID: <8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>


On Oct 5, 2009, at 2:58 PM, Douglas Gregor wrote:

>
> On Oct 5, 2009, at 2:37 PM, Tanya Lattner wrote:
>
>> Hello,
>>
>> I want to do a check on function parameters similar to the  
>> "err_arg_with_address_space" check that I added in  
>> ActOnParamDeclarator (r83165). However, this time, I only want to  
>> perform the check if the function has a specific attribute. Is  
>> ActOnParamDeclarator the right place? I'm not seeing a way to get  
>> the function attribute there. Or, any suggestion on where to add  
>> this?
>
>
> ActOnParamDeclarator won't work, since that gets can get called by  
> the parser before we've seen the function attributes. I suggest  
> putting this check into ActOnFunctionDeclarator (e.g., where we  
> check for parameters of "void" type).
>

Awesome, thanks! At this point in ActOnFunctionDeclarator, do  
parameters know about their attributes? Specifically addr space  
qualifiers. I'm thinking no because it always seems to think the  
param's in addr space 0, but when I dump the QualType I can clearly  
see the addr space attribute and its non zero, but I assume it just  
hasn't been processed yet.

Is there place where both function and params have had their  
attributes seen that I can add a check?

Sorry, new to parsers :)

-Tanya

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/39f25d57/attachment.html 

From rjmccall at apple.com  Tue Oct  6 17:50:21 2009
From: rjmccall at apple.com (John McCall)
Date: Tue, 06 Oct 2009 15:50:21 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
	<FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
	<8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
Message-ID: <4ACBC9AD.4000201@apple.com>

Tanya Lattner wrote:
>
> On Oct 5, 2009, at 2:58 PM, Douglas Gregor wrote:
>
>>
>> On Oct 5, 2009, at 2:37 PM, Tanya Lattner wrote:
>>
>>> Hello,
>>>
>>> I want to do a check on function parameters similar to the 
>>> "err_arg_with_address_space" check that I added 
>>> in ActOnParamDeclarator (r83165). However, this time, I only want to 
>>> perform the check if the function has a specific attribute. 
>>> Is ActOnParamDeclarator the right place? I'm not seeing a way to get 
>>> the function attribute there. Or, any suggestion on where to add this?
>>
>> ActOnParamDeclarator won't work, since that gets can get called by 
>> the parser before we've seen the function attributes. I suggest 
>> putting this check into ActOnFunctionDeclarator (e.g., where we check 
>> for parameters of "void" type).
>>
>
> Awesome, thanks! At this point in ActOnFunctionDeclarator, do 
> parameters know about their attributes? Specifically addr space 
> qualifiers. I'm thinking no because it always seems to think the 
> param's in addr space 0, but when I dump the QualType I can clearly 
> see the addr space attribute and its non zero, but I assume it just 
> hasn't been processed yet.

ActOnFunctionDeclarator doesn't get called until all the parameters have 
finished parsing, so all the attributes, address spaces, etc. should be 
present.

Can you post a code example where it thinks the parameter is in address 
space 0 (I assume getAddressSpace() is returning 0)?

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/8baee6ce/attachment.html 

From dgregor at apple.com  Tue Oct  6 17:55:31 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 6 Oct 2009 15:55:31 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
	<FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
	<8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
Message-ID: <111DF156-D549-4F01-B02B-6972AC33FCE1@apple.com>


On Oct 6, 2009, at 3:44 PM, Tanya Lattner wrote:

>
> On Oct 5, 2009, at 2:58 PM, Douglas Gregor wrote:
>
>>
>> On Oct 5, 2009, at 2:37 PM, Tanya Lattner wrote:
>>
>>> Hello,
>>>
>>> I want to do a check on function parameters similar to the  
>>> "err_arg_with_address_space" check that I added in  
>>> ActOnParamDeclarator (r83165). However, this time, I only want to  
>>> perform the check if the function has a specific attribute. Is  
>>> ActOnParamDeclarator the right place? I'm not seeing a way to get  
>>> the function attribute there. Or, any suggestion on where to add  
>>> this?
>>
>>
>> ActOnParamDeclarator won't work, since that gets can get called by  
>> the parser before we've seen the function attributes. I suggest  
>> putting this check into ActOnFunctionDeclarator (e.g., where we  
>> check for parameters of "void" type).
>>
>
> Awesome, thanks! At this point in ActOnFunctionDeclarator, do  
> parameters know about their attributes? Specifically addr space  
> qualifiers. I'm thinking no because it always seems to think the  
> param's in addr space 0, but when I dump the QualType I can clearly  
> see the addr space attribute and its non zero, but I assume it just  
> hasn't been processed yet.


The address-space qualifier has probably migrated to the type of the  
parameter, rather than sitting on the parameter itself. You can use  
QualType::getAddressSpace() to figure out the address space of the  
parameter.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/6b477e6f/attachment.html 

From lattner at apple.com  Tue Oct  6 18:20:00 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 6 Oct 2009 16:20:00 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <4ACBC9AD.4000201@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
	<FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
	<8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
	<4ACBC9AD.4000201@apple.com>
Message-ID: <0E6F5E33-6F53-40DB-9D9D-706A43F8EC21@apple.com>


On Oct 6, 2009, at 3:50 PM, John McCall wrote:

> Tanya Lattner wrote:
>>
>>
>> On Oct 5, 2009, at 2:58 PM, Douglas Gregor wrote:
>>
>>>
>>> On Oct 5, 2009, at 2:37 PM, Tanya Lattner wrote:
>>>
>>>> Hello,
>>>>
>>>> I want to do a check on function parameters similar to the  
>>>> "err_arg_with_address_space" check that I added in  
>>>> ActOnParamDeclarator (r83165). However, this time, I only want to  
>>>> perform the check if the function has a specific attribute. Is  
>>>> ActOnParamDeclarator the right place? I'm not seeing a way to get  
>>>> the function attribute there. Or, any suggestion on where to add  
>>>> this?
>>>
>>>
>>> ActOnParamDeclarator won't work, since that gets can get called by  
>>> the parser before we've seen the function attributes. I suggest  
>>> putting this check into ActOnFunctionDeclarator (e.g., where we  
>>> check for parameters of "void" type).
>>>
>>
>> Awesome, thanks! At this point in ActOnFunctionDeclarator, do  
>> parameters know about their attributes? Specifically addr space  
>> qualifiers. I'm thinking no because it always seems to think the  
>> param's in addr space 0, but when I dump the QualType I can clearly  
>> see the addr space attribute and its non zero, but I assume it just  
>> hasn't been processed yet.
>
> ActOnFunctionDeclarator doesn't get called until all the parameters  
> have finished parsing, so all the attributes, address spaces, etc.  
> should be present.
>
> Can you post a code example where it thinks the parameter is in  
> address space 0 (I assume getAddressSpace() is returning 0)?
>

Yes, I'm using getAddressSpace().

Here is a simple example:
__attribute__((annotate("random"))) void foo(__attribute__ 
((address_space(1))) int *x);

At the end of ActOnFunctionDeclarator (right before the return) is  
where I have my check.

for (unsigned p = 0, NumParams = NewFD->getNumParams();
              p < NumParams; ++p) {
           ParmVarDecl *Param = NewFD->getParamDecl(p);
           QualType T = Param->getType();
           if (T.getAddressSpace() == 0) {
		// do stuff
	
	}
}

For some reason, getAddressSpace() is returning 0.

(gdb) p T.getAddressSpace()
$1 = 0
(gdb) p T.dump()
: int __attribute__((address_space(1)))*identifier
$2 = void


-Tanya

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/35d8615a/attachment-0001.html 

From john.thompson.jtsoftware at gmail.com  Tue Oct  6 18:26:10 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 6 Oct 2009 16:26:10 -0700
Subject: [cfe-dev] Visual Studio file end build error patch
Message-ID: <aad8390910061626x152e7747ie8300a7462d7a8ad@mail.gmail.com>

VC++ has a problem with there being no new line at the end of the file,
resulting in "unexpected end of file" build errors.  The enclosed patch
fixes the ones I see.

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/85c5f442/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileend.patch
Type: application/octet-stream
Size: 605 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/85c5f442/attachment.obj 

From mrs at apple.com  Tue Oct  6 18:37:19 2009
From: mrs at apple.com (Mike Stump)
Date: Tue, 6 Oct 2009 16:37:19 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <0E6F5E33-6F53-40DB-9D9D-706A43F8EC21@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
	<FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
	<8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
	<4ACBC9AD.4000201@apple.com>
	<0E6F5E33-6F53-40DB-9D9D-706A43F8EC21@apple.com>
Message-ID: <3409B432-B47B-4562-AA94-5B2898A67EEC@apple.com>

On Oct 6, 2009, at 4:20 PM, Tanya Lattner wrote:
> For some reason, getAddressSpace() is returning 0.

$ cat as.c
__attribute__((annotate("random"))) void foo(__attribute__ 
((address_space(1))) int *x) {
   *x = 0;
   x = 0;
}
$ /Developer/usr/bin/clang -emit-llvm -S as.c -o -
; ModuleID = 'as.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- 
i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64- 
f80:128:128"
target triple = "x86_64-apple-darwin10.0"

define void @foo(i32 addrspace(1)* %x) nounwind ssp {
   %x.addr = alloca i32 addrspace(1)*              ; <i32 addrspace(1) 
**> [#uses=3]
   store i32 addrspace(1)* %x, i32 addrspace(1)** %x.addr
   %1 = load i32 addrspace(1)** %x.addr            ; <i32 addrspace(1) 
*> [#uses=1]
   store i32 0, i32 addrspace(1)* %1
   store i32 addrspace(1)* null, i32 addrspace(1)** %x.addr
   ret void
}

The 1 is on the thing that x points to, not x itself?

From dgregor at apple.com  Tue Oct  6 18:38:00 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 6 Oct 2009 16:38:00 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <0E6F5E33-6F53-40DB-9D9D-706A43F8EC21@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
	<FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
	<8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
	<4ACBC9AD.4000201@apple.com>
	<0E6F5E33-6F53-40DB-9D9D-706A43F8EC21@apple.com>
Message-ID: <D72AB297-E72A-49B8-8CC3-8AC830213278@apple.com>


On Oct 6, 2009, at 4:20 PM, Tanya Lattner wrote:

>
> On Oct 6, 2009, at 3:50 PM, John McCall wrote:
>
>> Tanya Lattner wrote:
>>>
>>>
>>> On Oct 5, 2009, at 2:58 PM, Douglas Gregor wrote:
>>>
>>>>
>>>> On Oct 5, 2009, at 2:37 PM, Tanya Lattner wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I want to do a check on function parameters similar to the  
>>>>> "err_arg_with_address_space" check that I added in  
>>>>> ActOnParamDeclarator (r83165). However, this time, I only want  
>>>>> to perform the check if the function has a specific attribute.  
>>>>> Is ActOnParamDeclarator the right place? I'm not seeing a way to  
>>>>> get the function attribute there. Or, any suggestion on where to  
>>>>> add this?
>>>>
>>>>
>>>> ActOnParamDeclarator won't work, since that gets can get called  
>>>> by the parser before we've seen the function attributes. I  
>>>> suggest putting this check into ActOnFunctionDeclarator (e.g.,  
>>>> where we check for parameters of "void" type).
>>>>
>>>
>>> Awesome, thanks! At this point in ActOnFunctionDeclarator, do  
>>> parameters know about their attributes? Specifically addr space  
>>> qualifiers. I'm thinking no because it always seems to think the  
>>> param's in addr space 0, but when I dump the QualType I can  
>>> clearly see the addr space attribute and its non zero, but I  
>>> assume it just hasn't been processed yet.
>>
>> ActOnFunctionDeclarator doesn't get called until all the parameters  
>> have finished parsing, so all the attributes, address spaces, etc.  
>> should be present.
>>
>> Can you post a code example where it thinks the parameter is in  
>> address space 0 (I assume getAddressSpace() is returning 0)?
>>
>
> Yes, I'm using getAddressSpace().
>
> Here is a simple example:
> __attribute__((annotate("random"))) void foo(__attribute__ 
> ((address_space(1))) int *x);
>
> At the end of ActOnFunctionDeclarator (right before the return) is  
> where I have my check.
>
> for (unsigned p = 0, NumParams = NewFD->getNumParams();
>              p < NumParams; ++p) {
>           ParmVarDecl *Param = NewFD->getParamDecl(p);
>           QualType T = Param->getType();
>           if (T.getAddressSpace() == 0) {
> 		// do stuff
> 	
> 	}
> }
>
> For some reason, getAddressSpace() is returning 0.
>
> (gdb) p T.getAddressSpace()
> $1 = 0
> (gdb) p T.dump()
> : int __attribute__((address_space(1)))*identifier
> $2 = void

The address space qualifier here applies to the "int", not to the  
"int*". If you get T as a PointerType (T->getAs<PointerType>()) and  
look at its pointee type, you'll see an address-space-qualified "int".

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/221c25a0/attachment.html 

From lattner at apple.com  Tue Oct  6 18:38:18 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 6 Oct 2009 16:38:18 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <3409B432-B47B-4562-AA94-5B2898A67EEC@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
	<FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
	<8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
	<4ACBC9AD.4000201@apple.com>
	<0E6F5E33-6F53-40DB-9D9D-706A43F8EC21@apple.com>
	<3409B432-B47B-4562-AA94-5B2898A67EEC@apple.com>
Message-ID: <06ABEF34-CDAB-49A1-83B8-D5950B854012@apple.com>


On Oct 6, 2009, at 4:37 PM, Mike Stump wrote:

> On Oct 6, 2009, at 4:20 PM, Tanya Lattner wrote:
>> For some reason, getAddressSpace() is returning 0.
>
> $ cat as.c
> __attribute__((annotate("random"))) void foo(__attribute__ 
> ((address_space(1))) int *x) {
>  *x = 0;
>  x = 0;
> }
> $ /Developer/usr/bin/clang -emit-llvm -S as.c -o -
> ; ModuleID = 'as.c'
> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- 
> i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- 
> s0:64:64-f80:128:128"
> target triple = "x86_64-apple-darwin10.0"
>
> define void @foo(i32 addrspace(1)* %x) nounwind ssp {
>  %x.addr = alloca i32 addrspace(1)*              ; <i32 addrspace(1) 
> **> [#uses=3]
>  store i32 addrspace(1)* %x, i32 addrspace(1)** %x.addr
>  %1 = load i32 addrspace(1)** %x.addr            ; <i32 addrspace(1) 
> *> [#uses=1]
>  store i32 0, i32 addrspace(1)* %1
>  store i32 addrspace(1)* null, i32 addrspace(1)** %x.addr
>  ret void
> }
>
> The 1 is on the thing that x points to, not x itself?

Yes, you are correct. Sorry, my mistake! It is doing the right thing.

Sorry for the noise.

-Tanya

From mrs at apple.com  Tue Oct  6 18:39:52 2009
From: mrs at apple.com (Mike Stump)
Date: Tue, 6 Oct 2009 16:39:52 -0700
Subject: [cfe-dev] Visual Studio file end build error patch
In-Reply-To: <aad8390910061626x152e7747ie8300a7462d7a8ad@mail.gmail.com>
References: <aad8390910061626x152e7747ie8300a7462d7a8ad@mail.gmail.com>
Message-ID: <3F938E7E-E3BF-4D73-A4E6-F9899B9CBF09@apple.com>

On Oct 6, 2009, at 4:26 PM, John Thompson wrote:
> VC++ has a problem with there being no new line at the end of the  
> file, resulting in "unexpected end of file" build errors.  The  
> enclosed patch fixes the ones I see.

Fixed.  I have a dream, one day we'll have a build verifier for the  
simple to check style things.  :-)

From rjmccall at apple.com  Tue Oct  6 18:40:21 2009
From: rjmccall at apple.com (John McCall)
Date: Tue, 06 Oct 2009 16:40:21 -0700
Subject: [cfe-dev] Parameter check question
In-Reply-To: <0E6F5E33-6F53-40DB-9D9D-706A43F8EC21@apple.com>
References: <ED689046-59B8-4417-BD1A-C5767383AC67@apple.com>
	<FEDD6E95-094F-4F06-981C-38B285C96F30@apple.com>
	<8BC63CA3-0E0D-4F51-ACDC-E1C1205C063E@apple.com>
	<4ACBC9AD.4000201@apple.com>
	<0E6F5E33-6F53-40DB-9D9D-706A43F8EC21@apple.com>
Message-ID: <4ACBD565.7010002@apple.com>

Tanya Lattner wrote:
>
> On Oct 6, 2009, at 3:50 PM, John McCall wrote:
>
>> Tanya Lattner wrote:
>>>
>>> On Oct 5, 2009, at 2:58 PM, Douglas Gregor wrote:
>>>
>>>>
>>>> On Oct 5, 2009, at 2:37 PM, Tanya Lattner wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I want to do a check on function parameters similar to the 
>>>>> "err_arg_with_address_space" check that I added 
>>>>> in ActOnParamDeclarator (r83165). However, this time, I only want 
>>>>> to perform the check if the function has a specific attribute. 
>>>>> Is ActOnParamDeclarator the right place? I'm not seeing a way to 
>>>>> get the function attribute there. Or, any suggestion on where to 
>>>>> add this?
>>>>
>>>> ActOnParamDeclarator won't work, since that gets can get called by 
>>>> the parser before we've seen the function attributes. I suggest 
>>>> putting this check into ActOnFunctionDeclarator (e.g., where we 
>>>> check for parameters of "void" type).
>>>>
>>>
>>> Awesome, thanks! At this point in ActOnFunctionDeclarator, do 
>>> parameters know about their attributes? Specifically addr space 
>>> qualifiers. I'm thinking no because it always seems to think the 
>>> param's in addr space 0, but when I dump the QualType I can clearly 
>>> see the addr space attribute and its non zero, but I assume it just 
>>> hasn't been processed yet.
>>
>> ActOnFunctionDeclarator doesn't get called until all the parameters 
>> have finished parsing, so all the attributes, address spaces, etc. 
>> should be present.
>>
>> Can you post a code example where it thinks the parameter is in 
>> address space 0 (I assume getAddressSpace() is returning 0)?
>>
>
> Yes, I'm using getAddressSpace().
>
> Here is a simple example:
> __attribute__((annotate("random"))) void 
> foo(__attribute__((address_space(1))) int *x);

I'm pretty sure this is legal in TR18037.  Like 'const', address spaces 
can apply at any point in a type;  an address-space-qualified type says 
that the object is stored in a particular address space.  So x is a 
pointer (stored in the generic address space) to an object of type int 
(stored in address space 1).

The codegen implications of address spaces accrue to pointers into that 
address space, which is why you can't have auto variables with direct 
address space qualifications.

If for some reason you want to implement a stricter condition than 
TR18037 and forbid pointers into non-generic address spaces, you'll need 
to pull off the outermost pointer from the type.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/cbbb1839/attachment-0001.html 

From clattner at apple.com  Tue Oct  6 19:35:53 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 6 Oct 2009 17:35:53 -0700
Subject: [cfe-dev] Visual Studio file end build error patch
In-Reply-To: <3F938E7E-E3BF-4D73-A4E6-F9899B9CBF09@apple.com>
References: <aad8390910061626x152e7747ie8300a7462d7a8ad@mail.gmail.com>
	<3F938E7E-E3BF-4D73-A4E6-F9899B9CBF09@apple.com>
Message-ID: <D0CF6028-D2DB-4D70-81D0-F216DD3846DE@apple.com>


On Oct 6, 2009, at 4:39 PM, Mike Stump wrote:

> On Oct 6, 2009, at 4:26 PM, John Thompson wrote:
>> VC++ has a problem with there being no new line at the end of the
>> file, resulting in "unexpected end of file" build errors.  The
>> enclosed patch fixes the ones I see.
>
> Fixed.  I have a dream, one day we'll have a build verifier for the
> simple to check style things.  :-)

Impossible!  That would require a C++ frontend that you could reuse as  
a library!

-Chris

From kcathey2 at illinois.edu  Tue Oct  6 23:38:30 2009
From: kcathey2 at illinois.edu (Kevin Cathey)
Date: Tue, 6 Oct 2009 23:38:30 -0500
Subject: [cfe-dev] DocumentXML Assertion
Message-ID: <F25C2D31-BD6B-4F26-B46C-5E6BE96888F7@illinois.edu>

I saw this in some archives recently, but I didn't really see the question get answered.

I am trying to use the -ast-print-xml flag on clang front end, but on almost every file, I'm getting a crash after an assertion in Document.XML at line 51.

The command I am running is:
./clang -S -Xclang -ast-print-xml -o /tmp/output.xml MyClass.m

The assertion exactly is:
Assertion failed: (NodeStack.size() > 1 && "too much backtracking"), function toParent, file DocumentXML.cpp, line 51.

Is there a work-around until a fix can get in?

Thanks.

Kevin

-------------------------------------------------
Kevin Cathey
Department of Computer Science - College of Engineering
University of Illinois Urbana Champaign


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091006/9c5b5d7a/attachment.html 

From spellegrini at dps.uibk.ac.at  Wed Oct  7 09:31:08 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Wed, 07 Oct 2009 16:31:08 +0200
Subject: [cfe-dev] Install circumvented with NO_INSTALL
Message-ID: <4ACCA62C.3070305@dps.uibk.ac.at>

Dear all,
I am trying to compile and use the latest pre-release-2 of llvm-2.6 but 
now the default behaviour of the Makefile is to DO NOT install clang 
libraries. :(

How can I enable the generation of clang libraries? I don't see any 
option in the ./configure script.

regards, Simone P.

From dgregor at apple.com  Wed Oct  7 09:45:01 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 7 Oct 2009 07:45:01 -0700
Subject: [cfe-dev] Visual Studio file end build error patch
In-Reply-To: <D0CF6028-D2DB-4D70-81D0-F216DD3846DE@apple.com>
References: <aad8390910061626x152e7747ie8300a7462d7a8ad@mail.gmail.com>
	<3F938E7E-E3BF-4D73-A4E6-F9899B9CBF09@apple.com>
	<D0CF6028-D2DB-4D70-81D0-F216DD3846DE@apple.com>
Message-ID: <5CD64252-5514-4820-9FD2-295ECCE3EB39@apple.com>


On Oct 6, 2009, at 5:35 PM, Chris Lattner wrote:

>
> On Oct 6, 2009, at 4:39 PM, Mike Stump wrote:
>
>> On Oct 6, 2009, at 4:26 PM, John Thompson wrote:
>>> VC++ has a problem with there being no new line at the end of the
>>> file, resulting in "unexpected end of file" build errors.  The
>>> enclosed patch fixes the ones I see.
>>
>> Fixed.  I have a dream, one day we'll have a build verifier for the
>> simple to check style things.  :-)
>
> Impossible!  That would require a C++ frontend that you could reuse as
> a library!


... or a trivial Subversion pre-commit hook.

	- Doug

From dgregor at apple.com  Wed Oct  7 10:28:10 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 7 Oct 2009 08:28:10 -0700
Subject: [cfe-dev] DocumentXML Assertion
In-Reply-To: <F25C2D31-BD6B-4F26-B46C-5E6BE96888F7@illinois.edu>
References: <F25C2D31-BD6B-4F26-B46C-5E6BE96888F7@illinois.edu>
Message-ID: <BA359B2F-4B7C-46B6-911A-D956177EEFC9@apple.com>


On Oct 6, 2009, at 9:38 PM, Kevin Cathey wrote:

> I saw this in some archives recently, but I didn't really see the  
> question get answered.
>
> I am trying to use the -ast-print-xml flag on clang front end, but  
> on almost every file, I'm getting a crash after an assertion in  
> Document.XML at line 51.
>
> The command I am running is:
> ./clang -S -Xclang -ast-print-xml -o /tmp/output.xml MyClass.m
>
> The assertion exactly is:
> Assertion failed: (NodeStack.size() > 1 && "too much backtracking"),  
> function toParent, file DocumentXML.cpp, line 51.
>
> Is there a work-around until a fix can get in?


FWIW, XML output was a community contribution that is not being  
actively maintained. This (and other) problems with the XML output are  
unlikely to get resolved unless people are willing to provide patches  
to fix them.

	- Doug

From Axel.Naumann at cern.ch  Wed Oct  7 11:24:58 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Wed, 7 Oct 2009 18:24:58 +0200
Subject: [cfe-dev] headers install
Message-ID: <4ACCC0DA.9050707@cern.ch>

Hi,

after
  ../src/configure --prefix=/home/axel/build/llvm/inst \
--enable-debug-runtime --enable-targets=host-only \
--enable-llvmc-dynamic; make; make install

I get all llvm headers and libs installed, but only the clang libs -
none of he clang headers is installed. Is that intentional? What's the
proposed way for non-llvm projects to #include clang headers?

Cheers, Axel.

From Axel.Naumann at cern.ch  Wed Oct  7 11:30:02 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Wed, 7 Oct 2009 18:30:02 +0200
Subject: [cfe-dev] headers install
In-Reply-To: <4ACCC0DA.9050707@cern.ch>
References: <4ACCC0DA.9050707@cern.ch>
Message-ID: <4ACCC20A.7090408@cern.ch>

Hi,

I was wrong stating that the clang libs get installed - they don't. And
I only realize now that I am basically asking Simone's question again,
with the addition of "...and how to I get the clang *headers* installed?"

Cheers, Axel.

On 2009-10-07 18:24, Axel Naumann wrote:
> Hi,
> 
> after
>   ../src/configure --prefix=/home/axel/build/llvm/inst \
> --enable-debug-runtime --enable-targets=host-only \
> --enable-llvmc-dynamic; make; make install
> 
> I get all llvm headers and libs installed, but only the clang libs -
> none of he clang headers is installed. Is that intentional? What's the
> proposed way for non-llvm projects to #include clang headers?
> 
> Cheers, Axel.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 


From dgregor at apple.com  Wed Oct  7 11:44:34 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 7 Oct 2009 09:44:34 -0700
Subject: [cfe-dev] Install circumvented with NO_INSTALL
In-Reply-To: <4ACCA62C.3070305@dps.uibk.ac.at>
References: <4ACCA62C.3070305@dps.uibk.ac.at>
Message-ID: <6FBFCD9D-B68C-4D72-BFA2-89410F6DF434@apple.com>


On Oct 7, 2009, at 7:31 AM, Simone Pellegrini wrote:

> Dear all,
> I am trying to compile and use the latest pre-release-2 of llvm-2.6  
> but
> now the default behaviour of the Makefile is to DO NOT install clang
> libraries. :(

We don't currently install Clang libraries (or headers) because, at  
the time that we wrote the makefiles, we didn't consider them stable  
enough for external tools to be built on them. However, the interfaces  
are probably "stable enough" now (by LLVM's definition of API  
stability), that it's reasonable to start installing Clang libraries +  
headers.

> How can I enable the generation of clang libraries? I don't see any
> option in the ./configure script.


You would need to remove the

	NO_INSTALL = 1

lines from the Clang library makefiles and add some makefile magic to  
install the Clang headers. (Plus, CMake

	- Doug

From Axel.Naumann at cern.ch  Wed Oct  7 16:13:03 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Wed, 7 Oct 2009 23:13:03 +0200
Subject: [cfe-dev] Install circumvented with NO_INSTALL
In-Reply-To: <6FBFCD9D-B68C-4D72-BFA2-89410F6DF434@apple.com>
References: <4ACCA62C.3070305@dps.uibk.ac.at>
	<6FBFCD9D-B68C-4D72-BFA2-89410F6DF434@apple.com>
Message-ID: <4ACD045F.9050405@cern.ch>

Hi,

does this make sense? It works for me.

I copied the install-local rule from llvm/Makefile.rules to
clang/Makefile because it's slightly different. Let me know if I can
change anything.

Cheers, Axel.

On 2009-10-07 18:44, Douglas Gregor wrote:
> On Oct 7, 2009, at 7:31 AM, Simone Pellegrini wrote:
> 
>> Dear all,
>> I am trying to compile and use the latest pre-release-2 of llvm-2.6  
>> but
>> now the default behaviour of the Makefile is to DO NOT install clang
>> libraries. :(
> 
> We don't currently install Clang libraries (or headers) because, at  
> the time that we wrote the makefiles, we didn't consider them stable  
> enough for external tools to be built on them. However, the interfaces  
> are probably "stable enough" now (by LLVM's definition of API  
> stability), that it's reasonable to start installing Clang libraries +  
> headers.
> 
>> How can I enable the generation of clang libraries? I don't see any
>> option in the ./configure script.
> 
> 
> You would need to remove the
> 
> 	NO_INSTALL = 1
> 
> lines from the Clang library makefiles and add some makefile magic to  
> install the Clang headers. (Plus, CMake
> 
> 	- Doug
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang_install.diff.gz
Type: application/x-gzip
Size: 862 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091007/d9ba4d4f/attachment.gz 

From john.thompson.jtsoftware at gmail.com  Wed Oct  7 23:35:56 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 7 Oct 2009 21:35:56 -0700
Subject: [cfe-dev] Including windows.h, include paths
Message-ID: <aad8390910072135m7a4f5507v296e8c50094ce911@mail.gmail.com>

I was taking a crack at modifying Frontend/InitHeaderSearch.cpp to use the
Windows registry to find the Visual Studio installation directory, but find
that because of the /Za option used via cmake (disables Microsoft extensions
- ANSI only), windows.h won't compile.

As an experiment I took out the /Za option from the clang/CMakeLists.txt
file, but recompiling revealed some compile errors in some string class.
 Any thoughts on either how to make this work, or whether I should even be
trying to read the registry?

Note that using the registry would solve the problem of not being able to
see the environment variables when the tests are run.

I suppose I could hack up my own declarations for the needed registry
symbols, but that sounds bad.

On a related note, should not InitHeaderSearch also be using the target
triple information to determine which include path to use?  I've enclosed a
patch that attempts to do it.  This would be important for cross-compiling,
I gather.  It also has revised code for getting the Visual Studio include
path from the environment, plus the disabled code for the registry stuff.

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091007/9a429079/attachment.html 

From porterj at alum.rit.edu  Thu Oct  8 01:32:53 2009
From: porterj at alum.rit.edu (James Porter)
Date: Thu, 08 Oct 2009 01:32:53 -0500
Subject: [cfe-dev] [patch] Tests for C++ standard, section 5 (Expressions)
Message-ID: <hak12n$h1a$1@ger.gmane.org>

Attached is a handful of tests to verify that clang complies to the 
opening paragraphs of section 5 (Expressions) of the C++ standard.

Since this is the first time I've actually written tests designed to 
check standards compliance, I thought it'd be useful to get comments 
from people to make sure that I'm doing things right. If this patch is 
correct, I suppose it should also update the state of cxx_status.html? 
I'm not sure where that file is though.

- Jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expr-test.patch
Type: text/x-patch
Size: 2042 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091008/80970cc7/attachment.bin 

From spellegrini at dps.uibk.ac.at  Thu Oct  8 03:58:15 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Thu, 08 Oct 2009 10:58:15 +0200
Subject: [cfe-dev] LLVM Developer's meeting - Clang
Message-ID: <4ACDA9A7.2090504@dps.uibk.ac.at>

Dear CLANGers,
in our group we are really interested in Clang (as we are building tools 
based on it) and even more interested in the future directions.
A developer's meeting was held last week and we were looking forward to 
see the material which has been presented but so far... no slides have 
been uploaded. :(

Is there any plan to make those presentations available?

cheers, Simone P.
 


From dgregor at apple.com  Thu Oct  8 08:41:36 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 8 Oct 2009 06:41:36 -0700
Subject: [cfe-dev] LLVM Developer's meeting - Clang
In-Reply-To: <4ACDA9A7.2090504@dps.uibk.ac.at>
References: <4ACDA9A7.2090504@dps.uibk.ac.at>
Message-ID: <132E7786-B533-452F-B261-3EDC5B4C3295@apple.com>


On Oct 8, 2009, at 1:58 AM, Simone Pellegrini wrote:

> Dear CLANGers,
> in our group we are really interested in Clang (as we are building  
> tools
> based on it) and even more interested in the future directions.
> A developer's meeting was held last week and we were looking forward  
> to
> see the material which has been presented but so far... no slides have
> been uploaded. :(
>
> Is there any plan to make those presentations available?


Yes. We're working on it!

	- Doug

From rayfix.ml at gmail.com  Thu Oct  8 09:55:50 2009
From: rayfix.ml at gmail.com (Ray Fix)
Date: Thu, 8 Oct 2009 10:55:50 -0400
Subject: [cfe-dev] LLVM Developer's meeting - Clang
In-Reply-To: <132E7786-B533-452F-B261-3EDC5B4C3295@apple.com>
References: <4ACDA9A7.2090504@dps.uibk.ac.at>
	<132E7786-B533-452F-B261-3EDC5B4C3295@apple.com>
Message-ID: <86A2FD56-E280-41EE-B8DC-8888DE1C7787@gmail.com>

On Oct 8, 2009, at 9:41 AM, Douglas Gregor wrote:
>> Is there any plan to make those presentations available?
>
> Yes. We're working on it!

Hurry!  Every 24 hours that goes by is another missing backend could  
have been written.  :)

It sounds like the videos will be up in 2-4 weeks which is pretty good  
turn around time as far as those things go.  It would be great if some  
of the slides could be released before then.  (Yes, you may have  
guessed, I am trying to write a backend. ;-)

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091008/cf999a7d/attachment.html 

From spellegrini at dps.uibk.ac.at  Thu Oct  8 10:24:28 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Thu, 08 Oct 2009 17:24:28 +0200
Subject: [cfe-dev] LLVM Developer's meeting - Clang
In-Reply-To: <86A2FD56-E280-41EE-B8DC-8888DE1C7787@gmail.com>
References: <4ACDA9A7.2090504@dps.uibk.ac.at>	<132E7786-B533-452F-B261-3EDC5B4C3295@apple.com>
	<86A2FD56-E280-41EE-B8DC-8888DE1C7787@gmail.com>
Message-ID: <4ACE042C.8080603@dps.uibk.ac.at>

Ray Fix wrote:
> On Oct 8, 2009, at 9:41 AM, Douglas Gregor wrote:
>>> Is there any plan to make those presentations available?
>>
>> Yes. We're working on it!
>
> Hurry!  Every 24 hours that goes by is another missing backend could 
> have been written.  :)
>
> It sounds like the videos will be up in 2-4 weeks which is pretty good 
> turn around time as far as those things go.  It would be great if some 
> of the slides could be released before then.  (Yes, you may have 
> guessed, I am trying to write a backend. ;-)
Actually I am more interested in the slides than the videos.
Anyway, good to know that they will be available, I will wait... I am 
not in a hurry, I am a PhD student! AhauAh... :(

cheers, Simone
>
> Ray
> ------------------------------------------------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>   


From clattner at apple.com  Thu Oct  8 10:49:37 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 8 Oct 2009 08:49:37 -0700
Subject: [cfe-dev] LLVM Developer's meeting - Clang
In-Reply-To: <86A2FD56-E280-41EE-B8DC-8888DE1C7787@gmail.com>
References: <4ACDA9A7.2090504@dps.uibk.ac.at>
	<132E7786-B533-452F-B261-3EDC5B4C3295@apple.com>
	<86A2FD56-E280-41EE-B8DC-8888DE1C7787@gmail.com>
Message-ID: <3D3CE264-6D5F-45B8-9E5B-C66B656BA845@apple.com>


On Oct 8, 2009, at 7:55 AM, Ray Fix wrote:

> On Oct 8, 2009, at 9:41 AM, Douglas Gregor wrote:
>>> Is there any plan to make those presentations available?
>>
>> Yes. We're working on it!
>
> Hurry!  Every 24 hours that goes by is another missing backend could  
> have been written.  :)
>
> It sounds like the videos will be up in 2-4 weeks which is pretty  
> good turn around time as far as those things go.  It would be great  
> if some of the slides could be released before then.  (Yes, you may  
> have guessed, I am trying to write a backend. ;-)

We're working on it, the slides will almost certainly be made  
available before the videos.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091008/b6b5b4fd/attachment-0001.html 

From john.thompson.jtsoftware at gmail.com  Thu Oct  8 14:08:16 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 8 Oct 2009 12:08:16 -0700
Subject: [cfe-dev] Windows patches
Message-ID: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>

Hi,

I haven't heard back about some of the patches I've posted over the last few
weeks.  Some did get some discussion and I reworked them, but the final
patch hasn't made it in yet.  Here's a big patch file with my accumulated
changes, which I will summarize below, fresh after an update.

Could someone help me out by evaluating them, and submit them, or give me
some feedback so I can rework them?

Basically my goal is to get all the tests passing on Windows, and most of
these relate to that.  There are still 23 failing tests, but some of them
have similar problems, so the feedback from these might help me know the
most appropriate way to deal with them, and avoid wasting time doing stuff
that's not appropriate.

Also, if you'd prefer I do patches in a different way, i.e. do one file at a
time, groups of similar changes, or just one big one for the remaining 23
failures, or post these to cfe-commits instead, please let me know what
works best for you.

The summaries:

test/CodeGenCXX/predefined-expr.cpp:
CodeGenObjC/predefined-expr.m:
test/CodeGen/stack-protector.c:

The above all comment out the stdio.h inclusion and instead declare printf,
to avoid problems parsing VC++'s stdio.h, particularly if a different target
triple is specified.

test/Driver/darwin-ld.c:
test/Driver/darwin-as.c:

Add a "*" to the grep or FileCheck string to account for the ".EXE" on
windows.

test/CodeGen/address-space-field2.c:
test/CodeGen/address-space-field3.c:
test/CodeGen/address-space-field4.c:

Converted to FileCheck to avoid problems with grep on Windows.

test/CodeGen/const-init.c:
test/CodeGen/cast-to-union.c:

In VC++, the *printf functions put an extra "0" in the exponent part of a
floating point number.  This add regular expressions to account for this.

include/clang/Frontend/InitHeaderSearch.h:
lib/Frontend/InitHeaderSearch.cpp:
tools/clang-cc/clang-cc.cpp:

This is a slight revision to the patch I posted yesterday to have the
default include path code use the target triple, as the line numbers were
off due to some other changes.  It also sets up include paths for VC++ and
Cygwin headers, along with the existing MinGW headers, plus the newer 4.4.0
version.  Note that running the tests with the MinGW headers results in 40
or more failed tests.  Currently, with this patch, only 23 tests are failing
with the VC++ headers.  I did leave in some disabled code regarding the
question I posted yesterday about including windows.h for the registry
stuff.

include/clang/Lex/LiteralSupport.h:
lib/Lex/LiteralSupport.cpp:

This fixes support for complex literals, reworked to avoid a goto, and to
add a flag noting the presence of a Microsoft extension suffix (i8, i16,
i32, i64).

lib/Basic/Targets.cpp:

Someone pointed out that in my previous Targets.cpp patch I didn't handle
the long size difference for one of the Windows targets.  This fixes that.

lib/Headers/stdint.h:

I think I got this from Daniel.  I believe it fixes some failing tests.

-John

P.S.  Is there some reason why the VC++ buildbot is off-line?

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091008/d065f49b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32all.patch
Type: application/octet-stream
Size: 33792 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091008/d065f49b/attachment-0001.obj 

From dchapiesky at yahoo.com  Thu Oct  8 15:46:38 2009
From: dchapiesky at yahoo.com (dan chap)
Date: Thu, 8 Oct 2009 13:46:38 -0700 (PDT)
Subject: [cfe-dev] Indexer Library and type references....
In-Reply-To: <1868934C-AE3A-45F0-B54F-F9D134B0C74C@apple.com>
Message-ID: <217875.93414.qm@web112508.mail.gq1.yahoo.com>



--- On M
Shifting namespaces sounds like a syntactic transformation rather than a transformation that needs to work on the AST.


Yes... It is syntactic...?? I am working on a refactoring tool (ala Netbeans Refactor/Rename) and I am using the Clang AST and indexer library to produce source locations and references not only against the primary project you were working on, but also within projects which depend upon the primary one...??? 

For example... (this is a very simple example and not necessarily a good one at that...)

You have a large project which has been code reviewed and regression tested to within an inch of it's life.?? It uses zlib 1.1.0 and does a fine job.

References to zlib are sprinkled throughout hundreds of modules and locations.

Now, a new version of zlib is available: 1.2.3 and you need it's functionality for an additional module being created in the project.

By massively refactoring the source code of zlib 1.2.3 to a new namespace (not C++ , just plain vanilla C) so that you get something like zlib_123_deflate(), you will not namespace collisions between the old and new zlib when linking.

We have preserved our code reviewed source code and we have ensured that there is no weird stuff going on during the link cycle.

Anyway,? preserving code reviewed code is the primary purpose of my refactor tool...? 

I will be making a beta available to the group in a couple of weeks with a cute wxwidgets front end.? 




....but someone will need to go through and add this information for us to maintain all type source information for expressions and statements.

??? - Doug

That will probably be me... :)

Daniel




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091008/8ad466d2/attachment.html 

From dgregor at apple.com  Thu Oct  8 16:05:32 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 8 Oct 2009 14:05:32 -0700
Subject: [cfe-dev] Indexer Library and type references....
In-Reply-To: <217875.93414.qm@web112508.mail.gq1.yahoo.com>
References: <217875.93414.qm@web112508.mail.gq1.yahoo.com>
Message-ID: <AA14C584-CCEC-485E-BBBF-374A6A4D6115@apple.com>


On Oct 8, 2009, at 1:46 PM, dan chap wrote:


>
>
> --- On M
>
> Shifting namespaces sounds like a syntactic transformation rather  
> than a transformation that needs to work on the AST.
>
>
> Yes... It is syntactic...   I am working on a refactoring tool (ala  
> Netbeans Refactor/Rename) and I am using the Clang AST and indexer  
> library to produce source locations and references not only against  
> the primary project you were working on, but also within projects  
> which depend upon the primary one...
>
> For example... (this is a very simple example and not necessarily a  
> good one at that...)
>
> You have a large project which has been code reviewed and regression  
> tested to within an inch of it's life.   It uses zlib 1.1.0 and does  
> a fine job.
>
> References to zlib are sprinkled throughout hundreds of modules and  
> locations.
>
> Now, a new version of zlib is available: 1.2.3 and you need it's  
> functionality for an additional module being created in the project.
>
> By massively refactoring the source code of zlib 1.2.3 to a new  
> namespace (not C++ , just plain vanilla C) so that you get something  
> like zlib_123_deflate(), you will not namespace collisions between  
> the old and new zlib when linking.
>
> We have preserved our code reviewed source code and we have ensured  
> that there is no weird stuff going on during the link cycle.
>
> Anyway,  preserving code reviewed code is the primary purpose of my  
> refactor tool...

That makes sense. Clang AST + Indexer library were meant to support  
this kind of transformation; I hope it's working out for you.

> I will be making a beta available to the group in a couple of weeks  
> with a cute wxwidgets front end.

Cool.

> ...but someone will need to go through and add this information for  
> us to maintain all type source information for expressions and  
> statements.
>
>     - Doug
>
> That will probably be me... :)

Great!

	- Doug


From dgregor at apple.com  Thu Oct  8 16:38:52 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 8 Oct 2009 14:38:52 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <8A40E756-DB19-41AE-AEFF-C5E913E563E3@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
	<A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
	<6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>
	<CC5CD715-4884-4C00-BD9C-3232B10D7478@bitmover.com>
	<2596256F-DC97-407C-A25E-980D492AF6E0@bitmover.com>
	<8A40E756-DB19-41AE-AEFF-C5E913E563E3@bitmover.com>
Message-ID: <D6A9742E-DA60-42C9-87E8-AA2B23E027E2@apple.com>


On Oct 6, 2009, at 9:12 AM, Oscar Bonilla wrote:

> On Oct 5, 2009, at 11:37 PM, Oscar Bonilla wrote:
>
>> On Oct 5, 2009, at 9:46 PM, Oscar Bonilla wrote:
>>
>>> Is this any better?
>>
>> Still not quite right:
>
> Ok, this one seems to do the trick:
>
> <ob.patch>
>
> Testcases:
>
> <warn-unused-variables.c><warn-unused-variables.cpp>
>
> I ran "make test" and only got one failure:
>
> FAIL: Clang::Index/c-index-api-test.m (646 of 1636)
>
> which seems unrelated. I also compiled Adium with it and didn't get  
> any obvious false positives or false negatives.

Wonderful, thank you! I've committed this patch here:

	http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091005/022108.html

along with your suggested micro-optimization. We love optimizations of  
all kinds, and moving the isUsed() check first will save a lot of  
isa<> checks. Good catch!

	- Doug

From ob at bitmover.com  Thu Oct  8 16:48:39 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Thu, 8 Oct 2009 14:48:39 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <D6A9742E-DA60-42C9-87E8-AA2B23E027E2@apple.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
	<A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
	<6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>
	<CC5CD715-4884-4C00-BD9C-3232B10D7478@bitmover.com>
	<2596256F-DC97-407C-A25E-980D492AF6E0@bitmover.com>
	<8A40E756-DB19-41AE-AEFF-C5E913E563E3@bitmover.com>
	<D6A9742E-DA60-42C9-87E8-AA2B23E027E2@apple.com>
Message-ID: <8C074AAA-650E-4FEC-BA92-CF23B17EB210@bitmover.com>

On Oct 8, 2009, at 2:38 PM, Douglas Gregor wrote:

>
> On Oct 6, 2009, at 9:12 AM, Oscar Bonilla wrote:
>
>> On Oct 5, 2009, at 11:37 PM, Oscar Bonilla wrote:
>>
>>> On Oct 5, 2009, at 9:46 PM, Oscar Bonilla wrote:
>>>
>>>> Is this any better?
>>>
>>> Still not quite right:
>>
>> Ok, this one seems to do the trick:
>>
>> <ob.patch>
>>
>> Testcases:
>>
>> <warn-unused-variables.c><warn-unused-variables.cpp>
>>
>> I ran "make test" and only got one failure:
>>
>> FAIL: Clang::Index/c-index-api-test.m (646 of 1636)
>>
>> which seems unrelated. I also compiled Adium with it and didn't get  
>> any obvious false positives or false negatives.
>
> Wonderful, thank you! I've committed this patch here:
>
> 	http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091005/022108.html
>
> along with your suggested micro-optimization. We love optimizations  
> of all kinds, and moving the isUsed() check first will save a lot of  
> isa<> checks. Good catch!

Thanks. I have some other warning fixes that I'll post here (is here  
the best place?).

Also, should I close the bug? http://llvm.org/bugs/show_bug.cgi? 
id=4563 or is there someone responsible for that?

Cheers,

-Oscar


From mrs at apple.com  Thu Oct  8 16:54:42 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 14:54:42 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <8EB96786-26E2-49AE-A375-F20D6FCF8D30@apple.com>

On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
>
> test/CodeGen/address-space-field2.c:
> test/CodeGen/address-space-field3.c:
> test/CodeGen/address-space-field4.c:
>
> Converted to FileCheck to avoid problems with grep on Windows.
>
> test/CodeGen/cast-to-union.c

I checked these bits in.

From mrs at apple.com  Thu Oct  8 17:00:20 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 15:00:20 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <504622FB-8BBC-4296-A8D7-D9AAA8A5AA3B@apple.com>

On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
> test/CodeGen/const-init.c:

And this bit. :-)

From dgregor at apple.com  Thu Oct  8 17:10:09 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 8 Oct 2009 15:10:09 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <76B35CCE-6810-4302-9D81-944D4C8646A8@apple.com>


On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
>
> P.S.  Is there some reason why the VC++ buildbot is off-line?


I don't know why, but Daniel (who administers the VC++ buildbot) is on  
vacation for another week or so. I expect that he'll bring it back  
online once he gets back.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091008/382f7dc7/attachment.html 

From dgregor at apple.com  Thu Oct  8 17:16:22 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 8 Oct 2009 15:16:22 -0700
Subject: [cfe-dev] Install circumvented with NO_INSTALL
In-Reply-To: <4ACD045F.9050405@cern.ch>
References: <4ACCA62C.3070305@dps.uibk.ac.at>
	<6FBFCD9D-B68C-4D72-BFA2-89410F6DF434@apple.com>
	<4ACD045F.9050405@cern.ch>
Message-ID: <655751B8-C700-4319-8A99-56E74BE50B36@apple.com>


On Oct 7, 2009, at 2:13 PM, Axel Naumann wrote:

> Hi,
>
> does this make sense? It works for me.
>
> I copied the install-local rule from llvm/Makefile.rules to
> clang/Makefile because it's slightly different. Let me know if I can
> change anything.

The looks good, committed here:

	http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091005/022113.html

However, it would be nice if we could avoid installing include/clang/ 
CMakeLists.txt.

	- Doug

From dgregor at apple.com  Thu Oct  8 17:17:51 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 8 Oct 2009 15:17:51 -0700
Subject: [cfe-dev] Implementing -Wunused-variables
In-Reply-To: <8C074AAA-650E-4FEC-BA92-CF23B17EB210@bitmover.com>
References: <AA0386A3-B86B-4355-9839-E58E91B1B35E@bitmover.com>
	<CD8CA9E4-A1B4-4F80-9C3F-62D64C77E327@apple.com>
	<9713B620-B063-4BA0-82D6-4E1DFA7A3AC3@bitmover.com>
	<E84ACF71-1E7A-480C-B0DC-F3470939FC37@bitmover.com>
	<A3F112C1-6BE0-4C4B-A2F9-A67CBC5FC159@bitmover.com>
	<6C042C25-13FC-4070-84ED-C1A1F97B05F3@apple.com>
	<CC5CD715-4884-4C00-BD9C-3232B10D7478@bitmover.com>
	<2596256F-DC97-407C-A25E-980D492AF6E0@bitmover.com>
	<8A40E756-DB19-41AE-AEFF-C5E913E563E3@bitmover.com>
	<D6A9742E-DA60-42C9-87E8-AA2B23E027E2@apple.com>
	<8C074AAA-650E-4FEC-BA92-CF23B17EB210@bitmover.com>
Message-ID: <76534D56-062D-4DEB-87B0-50225AF01606@apple.com>


On Oct 8, 2009, at 2:48 PM, Oscar Bonilla wrote:
> Thanks. I have some other warning fixes that I'll post here (is here  
> the best place?).

Generally, patches should go to cfe-commits, and someone will review  
them there.

> Also, should I close the bug? http://llvm.org/bugs/show_bug.cgi?id=4563 
>  or is there someone responsible for that?


Yes, you can go ahead and close the bug. Thanks!

	- Doug

From mrs at apple.com  Thu Oct  8 17:21:43 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 15:21:43 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <45CA7FC4-A2F7-4164-8B65-32785FCB5DFF@apple.com>

On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
> Could someone help me out by evaluating them,

For the change to VER, this isn't quite right.  svn should be used to  
manage the line encodings.  I double checked the file and it seems to  
be correct in svn?  If you remove the file and check it out again,  
does it come out correctly?  If it doesn't work, maybe a windows svn  
person could comment on the right fix.  svn:mime-type text would be  
the only other fix I know.

From mrs at apple.com  Thu Oct  8 17:31:22 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 15:31:22 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <6DEFF93E-42DD-460E-8C1C-B2A45F5971EC@apple.com>

On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
> test/Driver/darwin-ld.c:
> test/Driver/darwin-as.c:
>
> Add a "*" to the grep or FileCheck string to account for the ".EXE"  
> on windows.

Checked in.  Give darwin-ld.c a try, I changed it to .* instead of  
just *.  I'd expect that should work as well.

From dgregor at apple.com  Thu Oct  8 17:38:50 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 8 Oct 2009 15:38:50 -0700
Subject: [cfe-dev] [patch] Tests for C++ standard,
	section 5 (Expressions)
In-Reply-To: <hak12n$h1a$1@ger.gmane.org>
References: <hak12n$h1a$1@ger.gmane.org>
Message-ID: <317EDEE9-883A-4674-87BB-2E5F460050AA@apple.com>


On Oct 7, 2009, at 11:32 PM, James Porter wrote:

> Attached is a handful of tests to verify that clang complies to the  
> opening paragraphs of section 5 (Expressions) of the C++ standard.
>
> Since this is the first time I've actually written tests designed to  
> check standards compliance, I thought it'd be useful to get comments  
> from people to make sure that I'm doing things right.

These tests look good to me, thanks! I've committed them here:

	http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091005/022118.html

> If this patch is correct, I suppose it should also update the state  
> of cxx_status.html? I'm not sure where that file is though.

Yes, the patch should update cxx_status.html, which resides in the  
"www" subdirectory of the Clang tree. I've made the appropriate change  
as part of committing your tests.

One minor thing: since you're using Thunderbird, please follow the  
suggestions for Thunderbird users here:

	http://llvm.org/docs/DeveloperPolicy.html#patches

That makes it easier for users of Apple's Mail application to evaluate  
your patches.

	- Doug

From dgregor at apple.com  Thu Oct  8 17:51:20 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 8 Oct 2009 15:51:20 -0700
Subject: [cfe-dev] Including windows.h, include paths
In-Reply-To: <aad8390910072135m7a4f5507v296e8c50094ce911@mail.gmail.com>
References: <aad8390910072135m7a4f5507v296e8c50094ce911@mail.gmail.com>
Message-ID: <66AB2C22-445E-437F-A646-3548B9BA0D46@apple.com>


On Oct 7, 2009, at 9:35 PM, John Thompson wrote:

> I was taking a crack at modifying Frontend/InitHeaderSearch.cpp to  
> use the Windows registry to find the Visual Studio installation  
> directory, but find that because of the /Za option used via cmake  
> (disables Microsoft extensions - ANSI only), windows.h won't compile.
>
> As an experiment I took out the /Za option from the clang/ 
> CMakeLists.txt file, but recompiling revealed some compile errors in  
> some string class.
> Any thoughts on either how to make this work, or whether I should  
> even be trying to read the registry?

I think that using the registry to find Visual Studio is exactly the  
right solution. If the code that includes windows.h is segregated into  
a separate .cpp file, we can add whatever /Z??? flag is needed to make  
that one file handle windows.h

> On a related note, should not InitHeaderSearch also be using the  
> target triple information to determine which include path to use?   
> I've enclosed a patch that attempts to do it.  This would be  
> important for cross-compiling, I gather.  It also has revised code  
> for getting the Visual Studio include path from the environment,  
> plus the disabled code for the registry stuff.

I agree that InitHeaderSearch should use target triple information to  
determine which include paths to use.

	- Doug

From mrs at apple.com  Thu Oct  8 18:00:30 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 16:00:30 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <A2969653-0D7C-40FE-AC49-061AF49A7BC0@apple.com>

On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
> include/clang/Lex/LiteralSupport.h:
> lib/Lex/LiteralSupport.cpp:
>
> This fixes support for complex literals, reworked to avoid a goto,  
> and to add a flag noting the presence of a Microsoft extension  
> suffix (i8, i16, i32, i64).

Checked in.

> lib/Basic/Targets.cpp:
>
> Someone pointed out that in my previous Targets.cpp patch I didn't  
> handle the long size difference for one of the Windows targets.   
> This fixes that.

Checked in.

From mrs at apple.com  Thu Oct  8 18:05:42 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 16:05:42 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <AC8C4E3A-A30F-4A4D-B75C-D1695A43C71D@apple.com>

On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
>
> test/CodeGenCXX/predefined-expr.cpp:
> CodeGenObjC/predefined-expr.m:
> test/CodeGen/stack-protector.c:
>
> The above all comment out the stdio.h inclusion and instead declare  
> printf, to avoid problems parsing VC++'s stdio.h, particularly if a  
> different target triple is specified.

I put these in to speed up testing, which is always nice.

From mrs at apple.com  Thu Oct  8 18:33:25 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 16:33:25 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <5FDD0330-FD0C-4B06-9401-E8E944954929@apple.com>

On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
>
> include/clang/Frontend/InitHeaderSearch.h:
> lib/Frontend/InitHeaderSearch.cpp:
> tools/clang-cc/clang-cc.cpp:
>
> This is a slight revision to the patch I posted yesterday to have  
> the default include path code use the target triple, as the line  
> numbers were off due to some other changes.  It also sets up include  
> paths for VC++ and Cygwin headers, along with the existing MinGW  
> headers, plus the newer 4.4.0 version.  Note that running the tests  
> with the MinGW headers results in 40 or more failed tests.   
> Currently, with this patch, only 23 tests are failing with the VC++  
> headers.  I did leave in some disabled code regarding the question I  
> posted yesterday about including windows.h for the registry stuff.

I've checked this in, along with some minor whitespacing issues.   
Please keep lines to 80 columns.  Also, be sure to detab the files as  
well.  In some editors, there is a setting to avoid the use of hard  
tabs.

I think the windows code should be boosted out to a new file, and  
hidden away from us mere mortals.  In general #if in files is to be  
discouraged.

From mrs at apple.com  Thu Oct  8 18:38:47 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 16:38:47 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
Message-ID: <764844E5-81D1-4F6F-87D6-FCF0489D6E7C@apple.com>

On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
>
> lib/Headers/stdint.h:
>
> I think I got this from Daniel.  I believe it fixes some failing  
> tests.

Ick.  You'll have to discover some other way to do this.  If there is  
a #define that is specific to this environment, you can test that.   
You can read through:

   $ clang -E -dD -xc /dev/null

and see if any spring to mind.  If not, you can add one or a feature  
test for this and use it.

Aside from that, I think the rest of the patch has now been checked  
in.  If there are any pieces I missed, please svn up, and send in  
what's missing.  And welcome.

From john.thompson.jtsoftware at gmail.com  Thu Oct  8 19:42:04 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 8 Oct 2009 17:42:04 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <5FDD0330-FD0C-4B06-9401-E8E944954929@apple.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
	<5FDD0330-FD0C-4B06-9401-E8E944954929@apple.com>
Message-ID: <aad8390910081742m2e1b33eeleae70ce2c0bc6905@mail.gmail.com>

Thanks, Mike.

Can you give me some pointers on how to do a platform-specific file?  I
don't see any examples, and I don't know cmake.  For example, have a
"windows" subdirectory, and some conditional in the CMakeLists.txt file?
And how to make sure make doesn't pick up the file.

I figure the Basic library might be a good place for it.

Note that I found some errors in the registry part of it, and I'm
experimenting with getting the windows.h include to work.

> Aside from that, I think the rest of the patch has now been checked in.
If there are any pieces I missed, please svn up, and send in what's
missing.  And welcome.

You got them all, thanks!
-John
On Thu, Oct 8, 2009 at 4:33 PM, Mike Stump <mrs at apple.com> wrote:

> On Oct 8, 2009, at 12:08 PM, John Thompson wrote:
>
>>
>> include/clang/Frontend/InitHeaderSearch.h:
>> lib/Frontend/InitHeaderSearch.cpp:
>> tools/clang-cc/clang-cc.cpp:
>>
>> This is a slight revision to the patch I posted yesterday to have the
>> default include path code use the target triple, as the line numbers were
>> off due to some other changes.  It also sets up include paths for VC++ and
>> Cygwin headers, along with the existing MinGW headers, plus the newer 4.4.0
>> version.  Note that running the tests with the MinGW headers results in 40
>> or more failed tests.  Currently, with this patch, only 23 tests are failing
>> with the VC++ headers.  I did leave in some disabled code regarding the
>> question I posted yesterday about including windows.h for the registry
>> stuff.
>>
>
> I've checked this in, along with some minor whitespacing issues.  Please
> keep lines to 80 columns.  Also, be sure to detab the files as well.  In
> some editors, there is a setting to avoid the use of hard tabs.
>
> I think the windows code should be boosted out to a new file, and hidden
> away from us mere mortals.  In general #if in files is to be discouraged.
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091008/daca4dc9/attachment-0001.html 

From mrs at apple.com  Thu Oct  8 20:46:33 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 18:46:33 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910081742m2e1b33eeleae70ce2c0bc6905@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
	<5FDD0330-FD0C-4B06-9401-E8E944954929@apple.com>
	<aad8390910081742m2e1b33eeleae70ce2c0bc6905@mail.gmail.com>
Message-ID: <47B329FA-7D6E-479E-B4B3-D9DF5B240DF3@apple.com>

On Oct 8, 2009, at 5:42 PM, John Thompson wrote:
> Can you give me some pointers on how to do a platform-specific file?

Oh, there are lots of ways and llvm doesn't tend to have a beautiful  
way to do this...  but one way would be to arrange it like so:

#ifdef _MSC_VER
code
#endif

You can then just have it  built normally, and call the routines from  
the file from the other parts of the file.

So, for example, take a concepts called filename path canonicalization  
(just to pick a windows difference between unix).

Support/Paths.h:

   char *canonicalize(char *);

Support/UnixPaths.cpp:

   #ifndef _MSC_VER
   char *canonicalize(char *c) {
     while (c[0] == '/' && c[1] == '/') ++c;
     return c;
   }
   #endif

Support/WinPaths.cpp:

   #ifdef _MSC_VER
   char *canonicalize(char *c) {
     // ...
   }
   #endif

another approach would be llvm/lib/System/Atomic.cpp, though, I'm not  
sure I really like that style as much.  In general, one wraps up the  
system specific bits they want behind a system independent api, use  
that api in the main code, and then in the implementation, one can  
hide the details.

From clattner at apple.com  Fri Oct  9 00:04:22 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 8 Oct 2009 22:04:22 -0700
Subject: [cfe-dev] LLVM 2.6 release notes
Message-ID: <41C1F3C2-7C4B-4D02-B84C-EA55CBB75321@apple.com>

Hi All,

I added a blurb for clang in the 2.6 release notes:
http://llvm.org/docs/ReleaseNotes-2.6.html#clang

If you have suggestions for improvements, please let me know or update  
the entry directly, thanks!

-Chris

From Axel.Naumann at cern.ch  Fri Oct  9 02:24:24 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Fri, 9 Oct 2009 09:24:24 +0200
Subject: [cfe-dev] Install circumvented with NO_INSTALL
In-Reply-To: <655751B8-C700-4319-8A99-56E74BE50B36@apple.com>
References: <4ACCA62C.3070305@dps.uibk.ac.at>
	<6FBFCD9D-B68C-4D72-BFA2-89410F6DF434@apple.com>
	<4ACD045F.9050405@cern.ch>
	<655751B8-C700-4319-8A99-56E74BE50B36@apple.com>
Message-ID: <4ACEE528.2070603@cern.ch>

Hi Douglas,

Douglas Gregor wrote on 10/09/2009 12:16 AM:
> The looks good, committed here:
> 
>     http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091005/022113.html 

Thanks!

> However, it would be nice if we could avoid installing 
> include/clang/CMakeLists.txt.

Oops :-) Attached.

Cheers, Axel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang_install_no_CMakeLists.diff
Type: text/x-patch
Size: 609 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091009/5a85500a/attachment.bin 

From ob at bitmover.com  Fri Oct  9 11:22:53 2009
From: ob at bitmover.com (Oscar Bonilla)
Date: Fri, 9 Oct 2009 09:22:53 -0700
Subject: [cfe-dev] A better indent
Message-ID: <9EC346B4-2BED-4E5A-9711-35AF801E5D12@bitmover.com>

Hi,

As a second project for learning clang's internals I have decided to  
write a better indent. I just started looking at clang's source code  
(at the dev conference) so I would appreciate any pointers about where  
to start reading, etc. I can document how I go about learning it and  
hopefully produce some documentation.

For this part I'm especially interested in everything up to the AST  
and then going back from the AST to producing better formatted source  
code according to whatever criteria the user specifies.

Any suggestions on where to start?

Thanks,

-Oscar


From mrs at apple.com  Fri Oct  9 12:27:39 2009
From: mrs at apple.com (Mike Stump)
Date: Fri, 9 Oct 2009 10:27:39 -0700
Subject: [cfe-dev] A better indent
In-Reply-To: <9EC346B4-2BED-4E5A-9711-35AF801E5D12@bitmover.com>
References: <9EC346B4-2BED-4E5A-9711-35AF801E5D12@bitmover.com>
Message-ID: <10832BEA-20EE-44DC-86D0-F6A8FE43E8EB@apple.com>

On Oct 9, 2009, at 9:22 AM, Oscar Bonilla wrote:
> As a second project for learning clang's internals I have decided to
> write a better indent.

> Any suggestions on where to start?

My take...  Conceptualize this as an analysis checker.  The property  
you want to verify would be that the source is well indented.  So, for  
example:

   int i;

is poorly indented, as it doesn't start in column 0.  Indentation  
should always start at 0.  While this could be changed later, just  
take it is a given for now.  You check that the column of the int  
token is 0.  If it is not, you issue a warning for the indentation.   
Also, you can issue a fixit hint (see the fixit testsuite for what  
those look like, and that will guide you to the code that implements  
them) as well.  After you get that working, you should be able to get  
that to rewrite to:

int i;

The lexer knows when something is first on a line, you only want to  
apply the check, if what you're looking at is the first token on the  
line.  You might have to preserve or recreate that information.  I'd  
recommend not tying in directly to the parser as that would be a  
layering violation.  People that wanted a fast parser without that  
feature, don't want to pay for it.  Also, I think I'd nix this as a  
semantic check.

I'd recommend this a an analysis checker (lib/Analysis).  That  
framework allows for easy addition and removal of checks.  You'll be  
walking ASTs, starting from the top level forms.  At first, just check  
that the first top level form is in column 0.

That's step 1.

After that, you can start walking down the AST, and figuring out the  
increments to the nesting depths as you go.  You can have checks at  
the start of popular forms, such as declarations, statements and  
expressions, and get 90% of what you need.  CFG has an example of a  
something that walks the AST.  You can cheat off it for ideas.

My idea would be for you to actually check this into clang as you  
develop it.  I think it'd be cool to have.  Eventually, lib/Analysis  
may get a plugin architecture, and it in time, could just be a  
plugin.  An interesting mode would be to have a fairly permissive mode  
that merely checks for consistency.  That way, people could just use  
it, and not have to explain the formatting rules.  Hard parts would be  
to understand the headers can come from a different formatting domain  
as well as be external to the code.

Sounds cool, and welcome.

From Axel.Naumann at cern.ch  Fri Oct  9 15:04:08 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Fri, 9 Oct 2009 22:04:08 +0200
Subject: [cfe-dev] Install circumvented with NO_INSTALL
In-Reply-To: <4ACEE528.2070603@cern.ch>
References: <4ACCA62C.3070305@dps.uibk.ac.at>	<6FBFCD9D-B68C-4D72-BFA2-89410F6DF434@apple.com>	<4ACD045F.9050405@cern.ch>	<655751B8-C700-4319-8A99-56E74BE50B36@apple.com>
	<4ACEE528.2070603@cern.ch>
Message-ID: <4ACF9738.7080001@cern.ch>

Hi Doug,

On 2009-10-09 09:24, Axel Naumann wrote:
>> However, it would be nice if we could avoid installing
>> include/clang/CMakeLists.txt.
> 
> Oops :-) Attached.

I decided this falls into the "tiny build system patch" category. I
dared checking it in without explicit approval (r83665).

Cheers, Axel.

From dgregor at apple.com  Fri Oct  9 15:10:41 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Fri, 9 Oct 2009 13:10:41 -0700
Subject: [cfe-dev] Install circumvented with NO_INSTALL
In-Reply-To: <4ACF9738.7080001@cern.ch>
References: <4ACCA62C.3070305@dps.uibk.ac.at>
	<6FBFCD9D-B68C-4D72-BFA2-89410F6DF434@apple.com>
	<4ACD045F.9050405@cern.ch>
	<655751B8-C700-4319-8A99-56E74BE50B36@apple.com>
	<4ACEE528.2070603@cern.ch> <4ACF9738.7080001@cern.ch>
Message-ID: <4AF5F42F-5F4C-45E0-BDA0-6DD2A6A1467C@apple.com>


On Oct 9, 2009, at 1:04 PM, Axel Naumann wrote:

> Hi Doug,
>
> On 2009-10-09 09:24, Axel Naumann wrote:
>>> However, it would be nice if we could avoid installing
>>> include/clang/CMakeLists.txt.
>>
>> Oops :-) Attached.
>
> I decided this falls into the "tiny build system patch" category. I
> dared checking it in without explicit approval (r83665).

Yes, that's fine. Thanks!

	- Doug

From mrs at apple.com  Fri Oct  9 15:11:11 2009
From: mrs at apple.com (Mike Stump)
Date: Fri, 9 Oct 2009 13:11:11 -0700
Subject: [cfe-dev] Install circumvented with NO_INSTALL
In-Reply-To: <4ACF9738.7080001@cern.ch>
References: <4ACCA62C.3070305@dps.uibk.ac.at>
	<6FBFCD9D-B68C-4D72-BFA2-89410F6DF434@apple.com>
	<4ACD045F.9050405@cern.ch>
	<655751B8-C700-4319-8A99-56E74BE50B36@apple.com>
	<4ACEE528.2070603@cern.ch> <4ACF9738.7080001@cern.ch>
Message-ID: <BB0A7397-BFD4-439D-AA0F-88C55CA82D83@apple.com>

On Oct 9, 2009, at 1:04 PM, Axel Naumann wrote:
> On 2009-10-09 09:24, Axel Naumann wrote:
>>> However, it would be nice if we could avoid installing
>>> include/clang/CMakeLists.txt.
>>
>> Oops :-) Attached.
>
> I decided this falls into the "tiny build system patch" category. I
> dared checking it in without explicit approval (r83665).

Looks good, thanks.

From john.thompson.jtsoftware at gmail.com  Fri Oct  9 15:12:11 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Fri, 9 Oct 2009 13:12:11 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <47B329FA-7D6E-479E-B4B3-D9DF5B240DF3@apple.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
	<5FDD0330-FD0C-4B06-9401-E8E944954929@apple.com>
	<aad8390910081742m2e1b33eeleae70ce2c0bc6905@mail.gmail.com>
	<47B329FA-7D6E-479E-B4B3-D9DF5B240DF3@apple.com>
Message-ID: <aad8390910091312r748b524ey7d6258555696f212@mail.gmail.com>

Here's another crack at the windows include paths patch, using the registry
this time, with a fall back to the environment (if perhaps run on a
non-Windows system), with another fall back to hard-coded paths (if the env
vars are not set).  I also added an extra path that is typically defaulted
on Windows, the PlatformSDK/Include path, where all the Windows headers are.

I rearranged the code to try to localize the #ifdefs a bit more, but rather
than try to create a common place for system related things, I punted and
just left them in the file for now.
On thing you might not like is the hack to the CMakeLists.txt files I put
in, for working around the problem including windows.h because of the /Za
option.  But if anyone knows a better way...

-John
On Thu, Oct 8, 2009 at 6:46 PM, Mike Stump <mrs at apple.com> wrote:

> On Oct 8, 2009, at 5:42 PM, John Thompson wrote:
>
>> Can you give me some pointers on how to do a platform-specific file?
>>
>
> Oh, there are lots of ways and llvm doesn't tend to have a beautiful way to
> do this...  but one way would be to arrange it like so:
>
> #ifdef _MSC_VER
> code
> #endif
>
> You can then just have it  built normally, and call the routines from the
> file from the other parts of the file.
>
> So, for example, take a concepts called filename path canonicalization
> (just to pick a windows difference between unix).
>
> Support/Paths.h:
>
>  char *canonicalize(char *);
>
> Support/UnixPaths.cpp:
>
>  #ifndef _MSC_VER
>  char *canonicalize(char *c) {
>    while (c[0] == '/' && c[1] == '/') ++c;
>    return c;
>  }
>  #endif
>
> Support/WinPaths.cpp:
>
>  #ifdef _MSC_VER
>  char *canonicalize(char *c) {
>    // ...
>  }
>  #endif
>
> another approach would be llvm/lib/System/Atomic.cpp, though, I'm not sure
> I really like that style as much.  In general, one wraps up the system
> specific bits they want behind a system independent api, use that api in the
> main code, and then in the implementation, one can hide the details.
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091009/981a0d3f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: windows_include_paths_3.patch
Type: application/octet-stream
Size: 10765 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091009/981a0d3f/attachment-0001.obj 

From mrs at apple.com  Fri Oct  9 16:55:11 2009
From: mrs at apple.com (Mike Stump)
Date: Fri, 9 Oct 2009 14:55:11 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910091312r748b524ey7d6258555696f212@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
	<5FDD0330-FD0C-4B06-9401-E8E944954929@apple.com>
	<aad8390910081742m2e1b33eeleae70ce2c0bc6905@mail.gmail.com>
	<47B329FA-7D6E-479E-B4B3-D9DF5B240DF3@apple.com>
	<aad8390910091312r748b524ey7d6258555696f212@mail.gmail.com>
Message-ID: <DC6D7BE2-B1D2-4E86-9BD6-197EA8D9498D@apple.com>

On Oct 9, 2009, at 1:12 PM, John Thompson wrote:
> Here's another crack at the windows include paths patch

-/// RemoveDuplicates - If there are duplicate directory entries in  
the specified
-/// search list, remove the later (dead) ones.
+/// RemoveDuplicates - If there are duplicate directory entries in the
+/// specified search list, remove the later (dead) ones.

No, this was fine before.  Be sure to set your reflow column to be 80.


+bool getSystemRegistryString(const char *keyPath, const char  
*valueName,
+                       char *value, size_t maxLength) {
+  (void)keyPath;
+  (void)valueName;
+  (void)value;
+  (void)maxLength;
+  return(false);
+}

No, just omit the parameter name in the definition instead of cast to  
(void).


About the CMakeLists.txt change, ick.  Too much cut-n-paste  
programming.  If there is a way to say add this flag for this  
translation unit, that'd be best, second best would be to say, remove  
this flag for just this unit.  I was hoping there'd be a way to do  
that in just a few lines (like two, something like remove_flag 
(InitHeaderSearch.cpp, /Za)) or some such.  I'h hoping a cmake person  
can suggest something better.  Barring that, can you set a flag, check  
that in that flag in add_clang_library, and omit adding the /Za option?

From mtzrgb at gmail.com  Sat Oct 10 11:32:24 2009
From: mtzrgb at gmail.com (moataz ragab)
Date: Sat, 10 Oct 2009 18:32:24 +0200
Subject: [cfe-dev] how to build my clang based tool
Message-ID: <6dcf3dab0910100932v5e58b3d3r89936a2e6155be36@mail.gmail.com>

I would like to use the build system of llvm to build my tool that is based
on clang.

I made a new directory under clang/tools with the name of the tool
"polyextract". I copied the CMakelist.txt and Makefile from the clang-cc and
modified them
I then configure from llvm trunk and make, but unfortunately I only get the
object file generated and no executable is generated in the Debug/bin

I would appreciate your help. Sorry I am not familiar with the build
systems.

Attached are the files I modified

Thanks
Moataz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091010/0f90124f/attachment.html 
-------------- next part --------------
set(LLVM_NO_RTTI 1)

set( LLVM_USED_LIBS
  clangFrontend
  clangCodeGen
  clangAnalysis
  clangRewrite
  clangSema
  clangAST
  clangParse
  clangLex
  clangBasic
  )

set( LLVM_LINK_COMPONENTS
  bitreader
  bitwriter
  codegen
  ipo
  selectiondag
  )

add_clang_executable(polyextract
  polyextract.cpp
  )
add_dependencies(polyextract clang-headers)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 1075 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091010/0f90124f/attachment.obj 

From mtzrgb at gmail.com  Sat Oct 10 18:45:59 2009
From: mtzrgb at gmail.com (moataz ragab)
Date: Sun, 11 Oct 2009 01:45:59 +0200
Subject: [cfe-dev] how to build my clang based tool
In-Reply-To: <6dcf3dab0910100932v5e58b3d3r89936a2e6155be36@mail.gmail.com>
References: <6dcf3dab0910100932v5e58b3d3r89936a2e6155be36@mail.gmail.com>
Message-ID: <6dcf3dab0910101645k3ab23150hca2abca203c4f7de@mail.gmail.com>

I have managed to get it the executable generated by adding my directory to
the Makefile in clang/tools directory.

So in general here is what I had to t do
1. make a new directory with for the app
2. copy and modify the makefile and CMakelists.txt
3. add the subdirectory in the CMakelists.txt in clang/tools
4. add the directory to the DIRS variable in clang/tools/Makefile

So the LLVM and Clang uses a mix of cmake and Makefiles? Can you give an
abstract view of how the build process works?

Thanks,
Moataz

On Sat, Oct 10, 2009 at 6:32 PM, moataz ragab <mtzrgb at gmail.com> wrote:

> I would like to use the build system of llvm to build my tool that is based
> on clang.
>
> I made a new directory under clang/tools with the name of the tool
> "polyextract". I copied the CMakelist.txt and Makefile from the clang-cc and
> modified them
> I then configure from llvm trunk and make, but unfortunately I only get the
> object file generated and no executable is generated in the Debug/bin
>
> I would appreciate your help. Sorry I am not familiar with the build
> systems.
>
> Attached are the files I modified
>
> Thanks
> Moataz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091011/3accbad0/attachment.html 

From Axel.Naumann at cern.ch  Sun Oct 11 05:46:01 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Sun, 11 Oct 2009 12:46:01 +0200
Subject: [cfe-dev] how to build my clang based tool
In-Reply-To: <6dcf3dab0910101645k3ab23150hca2abca203c4f7de@mail.gmail.com>
References: <6dcf3dab0910100932v5e58b3d3r89936a2e6155be36@mail.gmail.com>
	<6dcf3dab0910101645k3ab23150hca2abca203c4f7de@mail.gmail.com>
Message-ID: <4AD1B769.4000404@cern.ch>

Hi Moataz,

On 2009-10-11 01:45, moataz ragab wrote:
> I have managed to get it the executable generated by adding my directory
> to the Makefile in clang/tools directory.

This is also what we do for our tool. Which reminds me that it would be
nice to have tools/Makefile and CMakeLists.txt automatically detect and
build additional tools. I'll suggest a patch.

> So the LLVM and Clang uses a mix of cmake and Makefiles? Can you give an
> abstract view of how the build process works?

LLVM can be built with either CMake or "../src/configure; make". They
are mostly equivalent.

Cheers, Axel.

> 
> On Sat, Oct 10, 2009 at 6:32 PM, moataz ragab <mtzrgb at gmail.com
> <mailto:mtzrgb at gmail.com>> wrote:
> 
>     I would like to use the build system of llvm to build my tool that
>     is based on clang.
> 
>     I made a new directory under clang/tools with the name of the tool
>     "polyextract". I copied the CMakelist.txt and Makefile from the
>     clang-cc and modified them
>     I then configure from llvm trunk and make, but unfortunately I only
>     get the object file generated and no executable is generated in the
>     Debug/bin
> 
>     I would appreciate your help. Sorry I am not familiar with the build
>     systems.
> 
>     Attached are the files I modified
> 
>     Thanks
>     Moataz
> 
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

From xuzhongxing at gmail.com  Sun Oct 11 21:33:17 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Mon, 12 Oct 2009 10:33:17 +0800
Subject: [cfe-dev] how to build my clang based tool
In-Reply-To: <6dcf3dab0910100932v5e58b3d3r89936a2e6155be36@mail.gmail.com>
References: <6dcf3dab0910100932v5e58b3d3r89936a2e6155be36@mail.gmail.com>
Message-ID: <5400aeb80910111933k59023e95w92af3c7e95aaff0a@mail.gmail.com>

The simple way is to use llvm/clang as static/shared libraries. You
can put your source files wherever you want, and write a Makefile
manually, like this:

INCLUDE = -I$(HOME)/llvm/include -I$(HOME)/llvm/tools/clang/include

CXXFLAGS = -g -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS \
           -fno-exceptions -fno-rtti \
           $(INCLUDE)

LIBS = -L$(HOME)/llvm/Debug/lib \
       -lclangFrontend \
       -lclangCodeGen \
       -lclangAnalysis \
       -lclangRewrite \
       -lclangSema \
       -lclangAST \
       -lclangParse \
       -lclangLex \
       -lclangBasic \
       -lclangIndex \
       -lLLVMBitWriter \
       -lLLVMAsmParser \
       -lLLVMArchive \
       -lLLVMBitReader \
       -lLLVMCore \
       -lLLVMSupport \
       -lLLVMSystem \
       -lLLVMCodeGen \
       -lLLVMAnalysis \
       -lLLVMTarget \
       -ldl -lpthread

HEADERS =

OBJS = foobar.o

foobar: $(OBJS) $(HEADERS)
	g++ -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -fno-exceptions -fno-rtti \
            -o $@ -g $(OBJS) $(LIBS)

On Sun, Oct 11, 2009 at 12:32 AM, moataz ragab <mtzrgb at gmail.com> wrote:
> I would like to use the build system of llvm to build my tool that is based
> on clang.
>
> I made a new directory under clang/tools with the name of the tool
> "polyextract". I copied the CMakelist.txt and Makefile from the clang-cc and
> modified them
> I then configure from llvm trunk and make, but unfortunately I only get the
> object file generated and no executable is generated in the Debug/bin
>
> I would appreciate your help. Sorry I am not familiar with the build
> systems.
>
> Attached are the files I modified
>
> Thanks
> Moataz
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>

From Vasudev.Negi at microchip.com  Sun Oct 11 22:55:38 2009
From: Vasudev.Negi at microchip.com (Vasudev.Negi at microchip.com)
Date: Sun, 11 Oct 2009 20:55:38 -0700
Subject: [cfe-dev] global variable named index
Message-ID: <F536B7C316F9474E9F7091239725AC9A03395619@CHN-CL-MAIL01.mchp-main.com>

If I have a global variable named index, clang-cc throws an error saying
redefinition of index as different kind of symbol. Why can't I have a
variable named index?

 

Thanks

Vasudev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091011/b7e48c85/attachment.html 

From clattner at apple.com  Sun Oct 11 22:57:41 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Oct 2009 20:57:41 -0700
Subject: [cfe-dev] global variable named index
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A03395619@CHN-CL-MAIL01.mchp-main.com>
References: <F536B7C316F9474E9F7091239725AC9A03395619@CHN-CL-MAIL01.mchp-main.com>
Message-ID: <A35997EA-A1F7-4330-B77D-54C65312D3EE@apple.com>


On Oct 11, 2009, at 8:55 PM, Vasudev.Negi at microchip.com wrote:

> If I have a global variable named index, clang-cc throws an error  
> saying redefinition of index as different kind of symbol. Why can?t  
> I have a variable named index?
>

'index' is the name of a function defined by the C standard library.   
Try 'man index' on the command line.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091011/5dac519d/attachment.html 

From mark at mirell.org  Mon Oct 12 04:39:33 2009
From: mark at mirell.org (Mark A. Miller)
Date: Mon, 12 Oct 2009 04:39:33 -0500
Subject: [cfe-dev] Cross-compiling with clang
In-Reply-To: <5BF49EAE-035B-48D6-9488-F71981D09477@apple.com>
References: <31014a580910022014p7dda3b8eyf80b051468fea77c@mail.gmail.com> 
	<5BF49EAE-035B-48D6-9488-F71981D09477@apple.com>
Message-ID: <31014a580910120239s134f9602rb6e036cd285ec28e@mail.gmail.com>

On Sat, Oct 3, 2009 at 1:28 AM, Chris Lattner <clattner at apple.com> wrote:
> On Oct 2, 2009, at 8:14 PM, Mark A. Miller wrote:
>
> As a preface, I am not a compiler developer, so please take my questions
> with a grain of salt. But there doesn't appear to be a clang-user mailing
> list, so I'm posting to -dev.
> I'm extremely interested in clang, since it both attempts to be saner than
> what gcc has become, and doesn't have the community forking licensing issues
> of GPLv2 and GPLv3. My recent projects have involved building
> cross-compilers for various targets, such as ARM, MIPS, PPC, sh4, et cetera.
> My main question is, has any work been done on allowing clang to
> cross-compile various targets? I found the following
> bug:?http://llvm.org/bugs/show_bug.cgi?id=4127 which indicated that it was
> still a work in progress.
> Also, I suppose this question may be better posed to the llvm list, but is
> there any documentation on how to use a gcc frontend and llvm backend to
> cross-compile?
> Lastly, and this is more of a slight nitpick issue, since I managed to find
> the bug with the following mailing list
> post:?http://article.gmane.org/gmane.comp.compilers.clang.devel/5893 I'd
> point out that the -arch feature currently only works on MacOSX. I wasted
> several hours trying to figure out what I was doing wrong on my Linux
> installation until I found ths out.
>
> Hi Mark,
> This is an area that we are actively interested in involving, but no one is
> driving yet. ?Are you interested in helping out? ?I'm not too familiar with
> the issues and Daniel (who is most knowledgeable about the driver) is out on
> vacation for 2 weeks.
> -Chris

Sorry for the late reply.

I'd be interested in helping in any capability I can.

I was mainly curious as to the current status of cross-compiling
aspect of clang, since I'm eager for it to supplant GPLv3ed gcc.

Thanks

-- 
Mark A. Miller
mark at mirell.org


From rich at pennware.com  Mon Oct 12 05:58:29 2009
From: rich at pennware.com (Richard Pennington)
Date: Mon, 12 Oct 2009 05:58:29 -0500
Subject: [cfe-dev] global variable named index
In-Reply-To: <A35997EA-A1F7-4330-B77D-54C65312D3EE@apple.com>
References: <F536B7C316F9474E9F7091239725AC9A03395619@CHN-CL-MAIL01.mchp-main.com>
	<A35997EA-A1F7-4330-B77D-54C65312D3EE@apple.com>
Message-ID: <4AD30BD5.2020200@pennware.com>

Chris Lattner wrote:
> 
> On Oct 11, 2009, at 8:55 PM, Vasudev.Negi at microchip.com 
> <mailto:Vasudev.Negi at microchip.com> wrote:
> 
>> If I have a global variable named index, clang-cc throws an error 
>> saying redefinition of index as different kind of symbol. Why can?t I 
>> have a variable named index?
>>  
> 
> 'index' is the name of a function defined by the C standard library. 
>  Try 'man index' on the command line.
> 

'index' was originally defined in BSD unix. It evolved into 'strchr'.
It is not part of the C standard library, nor is it a part of POSIX 
(since POSIX.1-2008).

According to the Linux man page, it is defined in "strings.h".

-Rich


From sanjiv.gupta at microchip.com  Mon Oct 12 06:05:42 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 12 Oct 2009 16:35:42 +0530
Subject: [cfe-dev] PATCH: Mangled Var name in Metadata.
Message-ID: <4AD30D86.5090501@microchip.com>

If a target has changed the variable name , it is not currently 
reflected in Debug Info Metadata. The attached patch gets the name from 
Var rather than the Decl, let me know if it is the right thing to do.

- Sanjiv

-- 
THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS
ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF
THE NAMED RECIPIENT(S).  ANY DISSEMINATION, DISTRIBUTION OR DUPLICATION
OF THIS TRANSMISSION IS STRICTLY PROHIBITED.

If you believe you have received this e-mail in error, please notify the
Sender and delete the e-mail from your system.

DISCLAIMER OF LIABILITY:

This transmittal and any accompanying information is for suggestion only
and is provided "AS IS".  It shall not be deemed to modify Microchip's
standard warranty for its products.  It is your responsibility to ensure
that this information meets your requirements.

MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR
OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR
PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION.  MICROCHIP PROVIDES
THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS.

To the fullest extent allowed by law, Microchip's liability shall not
exceed the amount of fee, if any, that you have paid directly to
Microchip for development of this information and associated services.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang.metadata.patch
Type: text/x-patch
Size: 550 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091012/06c0459d/attachment.bin 

From rdivacky at freebsd.org  Mon Oct 12 06:54:54 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Mon, 12 Oct 2009 13:54:54 +0200
Subject: [cfe-dev] ordering of asm constraints in clang CodeGen
Message-ID: <20091012115454.GA96866@freebsd.org>

hi

this simple code (coming from bug 879) on X86:

double
ldexp(double value, int exp)
{
        double temp, texp, temp2;
        texp = exp;

        __asm ("fscale " : "=u" (temp2), "=t" (temp) : "0" (texp), "1"
(value));
        return (temp);
}

is being handled by CGStmt.cpp:EmitAsmStmt(), the construction of output
constraints (ie. "=u" and "=t") is done simply from left to right. so this
particular example will construct output constraints of:


			st(1), st


according to X86FloatingPoint.cpp:handleSpecialFP()

  // FpGET_ST1 should occur right after a FpGET_ST0 for a call or inline asm.
  // The pattern we expect is:
  //  CALL
  //  FP1 = FpGET_ST0
  //  FP4 = FpGET_ST1
  //
  // At this point, we've pushed FP1 on the top of stack, so it should be
  // present if it isn't dead.  If it was dead, we already emitted a pop to
  // remove it from the stack and StackTop = 0.

(note that st(0) is the same as st)
the expected order of constrains is FpGET_ST0 and then FpGET_ST1 while clang
gives it in reverse. This leads to this assertion being hit:

Assertion failed: (StackTop == 0 && "Stack should be empty after a call!"), function handleSpecialFP, file
X86FloatingPoint.cpp, line 964.

can someone shed some light on this? is it true that llvm expects this order?
if so shouldnt clang order it this way? I need a little info about the situation
to be able to fix it.

Thank you!

Roman Divacky

From john.thompson.jtsoftware at gmail.com  Mon Oct 12 15:10:26 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Mon, 12 Oct 2009 13:10:26 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <DC6D7BE2-B1D2-4E86-9BD6-197EA8D9498D@apple.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
	<5FDD0330-FD0C-4B06-9401-E8E944954929@apple.com>
	<aad8390910081742m2e1b33eeleae70ce2c0bc6905@mail.gmail.com>
	<47B329FA-7D6E-479E-B4B3-D9DF5B240DF3@apple.com>
	<aad8390910091312r748b524ey7d6258555696f212@mail.gmail.com>
	<DC6D7BE2-B1D2-4E86-9BD6-197EA8D9498D@apple.com>
Message-ID: <aad8390910121310q40cc3f92jceec598b2179542a@mail.gmail.com>

Mike,

After reading some cmake docs, tutorials, and experimenting, here's the best
I could come up with.

There is a set_source_file_properties option, but unfortunately it doesn't
seem to let me undo the /Za option set in the macro via
set_target_properties, though it does let me add additional options.
Therefore, I have it re-call set_target_properties again, with the /Za
option edited out, thus affecting the whole library, which I hope won't be a
problem down the road.

There was a fixme comment about using AddGnuCPlusPlusIncludePaths, but MinGW
is not using the same directory structure.  Therefore, I added a helper
function specific to MinGW.  The MinGW64 stuff I guessed at, as I don't have
it installed, but I'll get it shortly and revise if needed.
If this is acceptable, should this be my test check-in?  Or should I try
something smaller first?

I'll move to cfe-commits after this.

-John
On Fri, Oct 9, 2009 at 2:55 PM, Mike Stump <mrs at apple.com> wrote:

> On Oct 9, 2009, at 1:12 PM, John Thompson wrote:
>
>> Here's another crack at the windows include paths patch
>>
>
> -/// RemoveDuplicates - If there are duplicate directory entries in the
> specified
> -/// search list, remove the later (dead) ones.
> +/// RemoveDuplicates - If there are duplicate directory entries in the
> +/// specified search list, remove the later (dead) ones.
>
> No, this was fine before.  Be sure to set your reflow column to be 80.
>
>
> +bool getSystemRegistryString(const char *keyPath, const char *valueName,
> +                       char *value, size_t maxLength) {
> +  (void)keyPath;
> +  (void)valueName;
> +  (void)value;
> +  (void)maxLength;
> +  return(false);
> +}
>
> No, just omit the parameter name in the definition instead of cast to
> (void).
>
>
> About the CMakeLists.txt change, ick.  Too much cut-n-paste programming.
>  If there is a way to say add this flag for this translation unit, that'd be
> best, second best would be to say, remove this flag for just this unit.  I
> was hoping there'd be a way to do that in just a few lines (like two,
> something like remove_flag(InitHeaderSearch.cpp, /Za)) or some such.  I'h
> hoping a cmake person can suggest something better.  Barring that, can you
> set a flag, check that in that flag in add_clang_library, and omit adding
> the /Za option?
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091012/b690220a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: windows_include_paths_4.patch
Type: application/octet-stream
Size: 11764 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091012/b690220a/attachment.obj 

From mrs at apple.com  Mon Oct 12 15:52:49 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 12 Oct 2009 13:52:49 -0700
Subject: [cfe-dev] Windows patches
In-Reply-To: <aad8390910121310q40cc3f92jceec598b2179542a@mail.gmail.com>
References: <aad8390910081208x7f1d174ekaa78f4b53158ff03@mail.gmail.com>
	<5FDD0330-FD0C-4B06-9401-E8E944954929@apple.com>
	<aad8390910081742m2e1b33eeleae70ce2c0bc6905@mail.gmail.com>
	<47B329FA-7D6E-479E-B4B3-D9DF5B240DF3@apple.com>
	<aad8390910091312r748b524ey7d6258555696f212@mail.gmail.com>
	<DC6D7BE2-B1D2-4E86-9BD6-197EA8D9498D@apple.com>
	<aad8390910121310q40cc3f92jceec598b2179542a@mail.gmail.com>
Message-ID: <4B4B8484-A558-48EF-929B-78920F2F4754@apple.com>

On Oct 12, 2009, at 1:10 PM, John Thompson wrote:
> After reading some cmake docs, tutorials, and experimenting, here's  
> the best I could come up with.

Looks better...  I checked it in, after fixing up some of the  
temporary issues.

> If this is acceptable, should this be my test check-in?  Or should I  
> try something smaller first?

Ah, oh well.  I'll let you check in the next one.  :-)

From Axel.Naumann at cern.ch  Tue Oct 13 08:04:58 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Tue, 13 Oct 2009 15:04:58 +0200
Subject: [cfe-dev] lookup from AST
Message-ID: <4AD47AFA.3080106@cern.ch>

Hi,

I need to access reflection gathered from some C++ code, e.g. which 
classes are defined, what data members does class "MyClass" have. My 
naive approach was to parse the source and query the resulting 
ASTContext using Sema, i.e. lookup "MyClass" and walk its decls. But 
Sema is a non-public API, which makes me wonder whether this is the 
right approach.

Is it?

Cheers, Axel.

From john.thompson.jtsoftware at gmail.com  Tue Oct 13 09:19:16 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 13 Oct 2009 07:19:16 -0700
Subject: [cfe-dev] Need Python help in TestRunner.py
Message-ID: <aad8390910130719r12729ca7m1519d581d04541ef@mail.gmail.com>

In running the test Driver/ast.c on Windows:

2>  File "C:\Tools\llvm\utils\lit\TestRunner.py", line 79, in executeShCmd
2>    raise NotImplementedError,"Unsupported redirect: %r" % (r,)
2>NotImplementedError: Unsupported redirect: (('>>',),
'C:\\Tools\\llvm\\tools\\clang\\test\\Driver\\Output\\ast.c.tmp')
It appears that '>>' is not one of the conditions in the if/else series, and
I don't know Python well enough to fix it.

My guess of adding:

            elif r[0] == ('>>',):
                redirects[1] = [r[1], 'a', None]
resulted in the redirected output being put at the front of the output file.
So if this is a quick fix for someone, I'd appreciate the help.

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/02221215/attachment-0001.html 

From daniel at zuster.org  Tue Oct 13 09:51:47 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Tue, 13 Oct 2009 17:51:47 +0300
Subject: [cfe-dev] Need Python help in TestRunner.py
In-Reply-To: <aad8390910130719r12729ca7m1519d581d04541ef@mail.gmail.com>
References: <aad8390910130719r12729ca7m1519d581d04541ef@mail.gmail.com>
Message-ID: <6a8523d60910130751t41c3f6c0qbe43dd1eb1390fe1@mail.gmail.com>

Hey John,

I'll try to take a look at this soon. File a bug or email me if I seem
to forget. :)

 - Daniel

On Tue, Oct 13, 2009 at 5:19 PM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> In running the test Driver/ast.c on Windows:
>
> 2>? File "C:\Tools\llvm\utils\lit\TestRunner.py", line 79, in executeShCmd
> 2>??? raise NotImplementedError,"Unsupported redirect: %r" % (r,)
> 2>NotImplementedError: Unsupported redirect: (('>>',),
> 'C:\\Tools\\llvm\\tools\\clang\\test\\Driver\\Output\\ast.c.tmp')
> It appears that '>>' is not one of the conditions in the if/else series, and
> I don't know Python well enough to fix it.
>
> My guess of adding:
>
> ??????????? elif r[0] == ('>>',):
> ??????????????? redirects[1] = [r[1], 'a', None]
> resulted in the redirected output being put at the front of the output file.
> So if this is a quick fix for someone, I'd appreciate the help.
>
> -John
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


From j.wilhelmy at arcor.de  Tue Oct 13 12:19:50 2009
From: j.wilhelmy at arcor.de (Jochen Wilhelmy)
Date: Tue, 13 Oct 2009 19:19:50 +0200
Subject: [cfe-dev] some newbie questions
Message-ID: <4AD4B6B6.3000603@arcor.de>

Hi!

I hope this is the right way to ask some newbie-questions about clang.

1. which option (clang::LangOptions) controls the overloading feature?
(e.g. int foo(int x); int foo(float x);)
is it possible to create a c-compiler with just overloading enabled 
additionally?

2. do I have to typedef vector types myself also in x=cl mode?
(e.g. typedef __attribute__(( ext_vector_type(4) )) float float4;)

3. how to I create a vector type in a expression? I want to write
a = b * float4(1, 2, 3, 4);
I get error: function-style cast to a builtin type can only take one 
argument.
Where can I patch this and would a patch be welcome or has it some
reason that it does not work?

4. how can I control the size of the builtin types (int, long etc.)?
I want to set long to 64 bit independent of the target architecture.


thanks and with kind regards,
jochen

From snaroff at apple.com  Tue Oct 13 12:50:47 2009
From: snaroff at apple.com (steve naroff)
Date: Tue, 13 Oct 2009 13:50:47 -0400
Subject: [cfe-dev] lookup from AST
In-Reply-To: <4AD47AFA.3080106@cern.ch>
References: <4AD47AFA.3080106@cern.ch>
Message-ID: <4C439CEA-4593-412B-9CAC-7C0D39336BB3@apple.com>

Hi Axel,

Sema is considered a transient object (whose 'output' is a well-formed  
AST).

The design is oriented toward creating an ASTConsumer. This 'callback'  
interface, combined with ASTContext's "get*" functions (and the  
respective AST's) should do the trick.

Did you try this? If we are missing some functionality in the AST, let  
us know (it is entirely possible that there is some logic that needs  
to move from Sema->AST).

snaroff

On Oct 13, 2009, at 9:04 AM, Axel Naumann wrote:

> Hi,
>
> I need to access reflection gathered from some C++ code, e.g. which
> classes are defined, what data members does class "MyClass" have. My
> naive approach was to parse the source and query the resulting
> ASTContext using Sema, i.e. lookup "MyClass" and walk its decls. But
> Sema is a non-public API, which makes me wonder whether this is the
> right approach.
>
> Is it?
>
> Cheers, Axel.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From juanc.martinez.santos at gmail.com  Tue Oct 13 13:08:49 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Tue, 13 Oct 2009 14:08:49 -0400
Subject: [cfe-dev] Clang - Getting Started
Message-ID: <d17b77a40910131108h3fdf64c3q5fc3a0c79bb2bca3@mail.gmail.com>

Hello,

I am following the Getting Starte steps... but I have some questions:


   1. (step 6) I got just "clang"... but in the web site appears "clang-cc"
   2. What can I expect when I use -fsyntax-only (check for correctness), I
   tried several errores, but I did not get anything
   3. When I used -emit-llvm (print out unoptimized llvm code), I got the
   following error:<clang: error: 'i386-pc-linux-gnu': unable to pass LLVM
   bit-code files to linker> What could be the error? I just followed the
   instructions.

I need to mention that I did not run the step 5. I am not interested on C++
(for now)

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/d643267e/attachment.html 

From john.thompson.jtsoftware at gmail.com  Tue Oct 13 14:10:50 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 13 Oct 2009 12:10:50 -0700
Subject: [cfe-dev] Clang - Getting Started
In-Reply-To: <d17b77a40910131108h3fdf64c3q5fc3a0c79bb2bca3@mail.gmail.com>
References: <d17b77a40910131108h3fdf64c3q5fc3a0c79bb2bca3@mail.gmail.com>
Message-ID: <aad8390910131210n537aec2el14f462ae80e82c27@mail.gmail.com>

clang-cc is the compiler front-end, and clang is the compiler driver.  After
a full make (or Visual Studio) build, both should be present among the
generated executables.  You might want to put the executable directory in
your path, however (at least on Windows, which is what I use).  On Windows
they are in llvm\bin\debug.  I forget where they are on Linux.

-John

On Tue, Oct 13, 2009 at 11:08 AM, Juan Carlos Martinez Santos <
juanc.martinez.santos at gmail.com> wrote:

> Hello,
>
> I am following the Getting Starte steps... but I have some questions:
>
>
>    1. (step 6) I got just "clang"... but in the web site appears
>    "clang-cc"
>    2. What can I expect when I use -fsyntax-only (check for correctness),
>    I tried several errores, but I did not get anything
>    3. When I used -emit-llvm (print out unoptimized llvm code), I got the
>    following error:<clang: error: 'i386-pc-linux-gnu': unable to pass LLVM
>    bit-code files to linker> What could be the error? I just followed the
>    instructions.
>
> I need to mention that I did not run the step 5. I am not interested on C++
> (for now)
>
> --
> Juan Carlos
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/e939eea3/attachment.html 

From john.thompson.jtsoftware at gmail.com  Tue Oct 13 15:02:15 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 13 Oct 2009 13:02:15 -0700
Subject: [cfe-dev] math.h on Windows
Message-ID: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>

There is a compile error when compiling VC++'s math.h.

Apparently, the GNU extentions are still enabled by default for Windows VC++
builds, in particular "_Complex".

This conflicts with the parameter name in:

_CRTIMP double  __cdecl _cabs(__in struct _complex _Complex);

During my investigation, I tried turning off the GNU extensions when the
Microsoft extensions are enabled, but this is problematic with a number of
the tests, which use _Complex, and probably lots of other places.  This
raised the question in my mind as to whether the GNU extensions should be
enabled in this case, but I figure it's probably better that way, making the
compiler more flexible.

Therefore, one way to make this work would be to change the parser a bit to
detect this case, and treat the _Complex token as an identifier in this
case.  The error originates from line 410 of DeclSpec.cpp.
Would this be a reasonable solution?

I haven't looked in to how to do this yet, but if you think it's a good
idea, I'll attempt it.

Actually, today there are two other errors in compiling this file, related
to wchar_t being defined already.  One solution is to define
_WCHAR_T_DEFINED for the Visual Studio targets, which will disable the
conflicting definition in crtdefs.h, and possibly elsewhere.  The enclosed
patch does this, which if you will approve it, I'll check it in.

To make the tests less dependent on headers, I've also enclosed a
mathtest.patch file for eliminating the math.h inclusion in the failed tests
I've looked at so far.

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/44f32f7d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wchart.patch
Type: application/octet-stream
Size: 950 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/44f32f7d/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mathtest.patch
Type: application/octet-stream
Size: 1446 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/44f32f7d/attachment-0001.obj 

From mrs at apple.com  Tue Oct 13 15:25:04 2009
From: mrs at apple.com (Mike Stump)
Date: Tue, 13 Oct 2009 13:25:04 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
Message-ID: <D5854649-B159-4058-AF80-F3BD70CF4880@apple.com>

On Oct 13, 2009, at 1:02 PM, John Thompson wrote:
> There is a compile error when compiling VC++'s math.h.

> To make the tests less dependent on headers, I've also enclosed a  
> mathtest.patch file for eliminating the math.h inclusion in the  
> failed tests I've looked at so far.

Please split out test/CodeGen/const-init.c.  I'd like someone else to  
review that, but the rest of mathtest.patch is fine.

From kcathey2 at illinois.edu  Tue Oct 13 17:41:57 2009
From: kcathey2 at illinois.edu (Kevin Cathey)
Date: Tue, 13 Oct 2009 17:41:57 -0500
Subject: [cfe-dev] AST references
Message-ID: <3EC36D9E-ABBD-4BDC-9F87-BC78D96F885E@illinois.edu>

I have the following file:

@protocol MyProtocol
- (void)someProtocolMethod;
@end

@interface MyBaseClass <MyProtocol> {
    id myIvar;
}
@end

When printing out the AST node for the @protocol declaration, I get:
$4 = {
  DeclKind = clang::Decl::ObjCProtocol, 
  ExternalLexicalStorage = false, 
  ExternalVisibleStorage = false, 
  LookupPtr = 0x0, 
  FirstDecl = 0x1033160c0, 
  LastDecl = 0x1033160c0
}

However, when I print out the AST node for <MyProtocol>, I get a different value:
$5 = {
  <clang::Decl> = {
    _vptr$Decl = 0x1016f80d0, 
    NextDeclInContext = 0x103316150, 
    DeclCtx = {
      Val = {
        Value = 4348516192
      }
    }, 
    Loc = {
      ID = 2
    }, 
    DeclKind = clang::Decl::ObjCProtocol, 
    InvalidDecl = 0, 
    HasAttrs = 0, 
    Implicit = false, 
    Used = false, 
    IdentifierNamespace = 16, 
    Access = 0
  }, 
  members of clang::NamedDecl: 
  Name = {
    Ptr = 4353910984
  }
}

I was under the impression that clang would resolve references. So MyProtocol would be the same in both places. If not, how do I resolve these references?

Thanks.

Kevin

-------------------------------------------------
Kevin Cathey
Department of Computer Science - College of Engineering
University of Illinois Urbana Champaign


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/ee5dcbba/attachment-0001.html 

From snaroff at apple.com  Tue Oct 13 17:55:51 2009
From: snaroff at apple.com (steve naroff)
Date: Tue, 13 Oct 2009 18:55:51 -0400
Subject: [cfe-dev] AST references
In-Reply-To: <3EC36D9E-ABBD-4BDC-9F87-BC78D96F885E@illinois.edu>
References: <3EC36D9E-ABBD-4BDC-9F87-BC78D96F885E@illinois.edu>
Message-ID: <7B46A84F-F8A7-4907-AC5A-353C194330DF@apple.com>

Hi Kevin,

In the example below, Protocol references are resolved by the  
ObjCInterfaceDecl API (e.g. the iterator on ObjCInterfaceDecl should  
return the ObjCProtocolDecl for 'MyProtocol').

In the debug output below, $4 looks like a 'DeclContext' (which  
ObjCProtocolDecl inherits from indirectly).

Let me know if you need further assistance,

snaroff

On Oct 13, 2009, at 6:41 PM, Kevin Cathey wrote:

> I have the following file:
>
> @protocol MyProtocol
> - (void)someProtocolMethod;
> @end
>
> @interface MyBaseClass <MyProtocol> {
>     id myIvar;
> }
> @end
>
> When printing out the AST node for the @protocol declaration, I get:
> $4 = {
>   DeclKind = clang::Decl::ObjCProtocol,
>   ExternalLexicalStorage = false,
>   ExternalVisibleStorage = false,
>   LookupPtr = 0x0,
>   FirstDecl = 0x1033160c0,
>   LastDecl = 0x1033160c0
> }
>
> However, when I print out the AST node for <MyProtocol>, I get a  
> different value:
> $5 = {
>   <clang::Decl> = {
>     _vptr$Decl = 0x1016f80d0,
>     NextDeclInContext = 0x103316150,
>     DeclCtx = {
>       Val = {
>         Value = 4348516192
>       }
>     },
>     Loc = {
>       ID = 2
>     },
>     DeclKind = clang::Decl::ObjCProtocol,
>     InvalidDecl = 0,
>     HasAttrs = 0,
>     Implicit = false,
>     Used = false,
>     IdentifierNamespace = 16,
>     Access = 0
>   },
>   members of clang::NamedDecl:
>   Name = {
>     Ptr = 4353910984
>   }
> }
>
> I was under the impression that clang would resolve references. So  
> MyProtocol would be the same in both places. If not, how do I  
> resolve these references?
>
> Thanks.
>
> Kevin
>
> -------------------------------------------------
> Kevin Cathey
> Department of Computer Science - College of Engineering
> University of Illinois Urbana Champaign
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/664caebf/attachment.html 

From devang.patel at gmail.com  Tue Oct 13 19:03:37 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Tue, 13 Oct 2009 17:03:37 -0700
Subject: [cfe-dev] PATCH: Mangled Var name in Metadata.
In-Reply-To: <4AD30D86.5090501@microchip.com>
References: <4AD30D86.5090501@microchip.com>
Message-ID: <352a1fb20910131703v460ffca4n78bb3ad94ebbcdf3@mail.gmail.com>

On Mon, Oct 12, 2009 at 4:05 AM, Sanjiv Gupta
<sanjiv.gupta at microchip.com> wrote:
> If a target has changed the variable name , it is not currently reflected in
> Debug Info Metadata. The attached patch gets the name from Var rather than
> the Decl, let me know if it is the right thing to do.
>

OK, go ahead.
I'm curious, why and how would target change global variable name ?

-
Devang

From dgregor at apple.com  Tue Oct 13 19:54:08 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 13 Oct 2009 17:54:08 -0700
Subject: [cfe-dev] some newbie questions
In-Reply-To: <4AD4B6B6.3000603@arcor.de>
References: <4AD4B6B6.3000603@arcor.de>
Message-ID: <17437D53-452E-404E-A1D3-43E68FDF1718@apple.com>

On Oct 13, 2009, at 10:19 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de>  
wrote:

> Hi!
>
> I hope this is the right way to ask some newbie-questions about clang.
>
> 1. which option (clang::LangOptions) controls the overloading feature?
> (e.g. int foo(int x); int foo(float x);)
> is it possible to create a c-compiler with just overloading enabled
> additionally?

There is no specific LangOptions flag for overloading, although of  
course it is available whe CPlusPlus is set.

That said, there is an "overloadable" attribute that permits  
overloading in C. It is documented on Clang's language extensions web  
page, and is used by C99's <tgmath.h> and OpenCL.

> 2. do I have to typedef vector types myself also in x=cl mode?
> (e.g. typedef __attribute__(( ext_vector_type(4) )) float float4;)

Yes.

> 3. how to I create a vector type in a expression? I want to write
> a = b * float4(1, 2, 3, 4);
> I get error: function-style cast to a builtin type can only take one
> argument.
> Where can I patch this and would a patch be welcome or has it some
> reason that it does not work?

Put parentheses around "float4"?

> 4. how can I control the size of the builtin types (int, long etc.)?
> I want to set long to 64 bit independent of the target architecture.

I think you either have to pick an architecure with 64-bit longs or  
create your own variant of an similar architecture (then override the  
size of long).

   - Doug

From clattner at apple.com  Tue Oct 13 19:58:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 13 Oct 2009 17:58:46 -0700
Subject: [cfe-dev] ordering of asm constraints in clang CodeGen
In-Reply-To: <20091012115454.GA96866@freebsd.org>
References: <20091012115454.GA96866@freebsd.org>
Message-ID: <7CBBD425-D7C3-4F3B-A51B-DD5F93614CE9@apple.com>


On Oct 12, 2009, at 4:54 AM, Roman Divacky wrote:

> hi
>
> this simple code (coming from bug 879) on X86:
>
> double
> ldexp(double value, int exp)
> {
>        double temp, texp, temp2;
>        texp = exp;
>
>        __asm ("fscale " : "=u" (temp2), "=t" (temp) : "0" (texp), "1"
> (value));
>        return (temp);
> }
>
> is being handled by CGStmt.cpp:EmitAsmStmt(), the construction of  
> output
> constraints (ie. "=u" and "=t") is done simply from left to right.  
> so this
> particular example will construct output constraints of:

Hi Roman,

As we discussed on IRC, this is really an llvm backend issue.  My  
memory is fuzzy here, but last time I tried to tackle this, I ran into  
problems where we really wanted a single merge FpGET_ST0/1 instruction  
produced by isel (I think) that the fpstackifier could deal with as  
one operation.  If we don't have that, then other load/stores etc can  
get in between the machine instructions.

-Chris

>
>
> 			st(1), st
>
>
> according to X86FloatingPoint.cpp:handleSpecialFP()
>
>  // FpGET_ST1 should occur right after a FpGET_ST0 for a call or  
> inline asm.
>  // The pattern we expect is:
>  //  CALL
>  //  FP1 = FpGET_ST0
>  //  FP4 = FpGET_ST1
>  //
>  // At this point, we've pushed FP1 on the top of stack, so it  
> should be
>  // present if it isn't dead.  If it was dead, we already emitted a  
> pop to
>  // remove it from the stack and StackTop = 0.
>
> (note that st(0) is the same as st)
> the expected order of constrains is FpGET_ST0 and then FpGET_ST1  
> while clang
> gives it in reverse. This leads to this assertion being hit:
>
> Assertion failed: (StackTop == 0 && "Stack should be empty after a  
> call!"), function handleSpecialFP, file
> X86FloatingPoint.cpp, line 964.
>
> can someone shed some light on this? is it true that llvm expects  
> this order?
> if so shouldnt clang order it this way? I need a little info about  
> the situation
> to be able to fix it.
>
> Thank you!
>
> Roman Divacky
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From john.thompson.jtsoftware at gmail.com  Tue Oct 13 21:23:14 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 13 Oct 2009 19:23:14 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <4AD50ED3.50007@gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<4AD50ED3.50007@gmail.com>
Message-ID: <aad8390910131923h1cf858d3m241b1f0516c1b524@mail.gmail.com>

Oh.  Interesting.  I just checked VC 9.0, and they renamed the parameter.
So I guess one solution is to just focus on VC9 for now.

The wchar_t problem persists, however.  So, may I check in my proposed
wchar_t fix?

-John
On Tue, Oct 13, 2009 at 4:35 PM, Sean Hunt <rideau3 at gmail.com> wrote:

> John Thompson wrote:
>
>> There is a compile error when compiling VC++'s math.h.
>>  Apparently, the GNU extentions are still enabled by default for Windows
>> VC++ builds, in particular "_Complex".
>>
>
> _Complex is not a GNU extension; it's a C99 keyword.
>
> Sean Hunt
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/82f2d120/attachment.html 

From kcathey2 at illinois.edu  Tue Oct 13 23:28:36 2009
From: kcathey2 at illinois.edu (Kevin Cathey)
Date: Tue, 13 Oct 2009 23:28:36 -0500
Subject: [cfe-dev] Should ObjCMethodDecl::getCanonicalDecl search superclass?
Message-ID: <D5355513-3BC4-4878-B4CF-66C030435B76@illinois.edu>

Should the getCanonicalDecl method on ObjCMethodDecl also search its superclasses? For example, if I have the following:

@interface MyBaseClass <MyProtocol> {
}
- (void)method1;
@end

@interface MyClass : MyBaseClass {
}
- (void)method2:(id)argument;
@end

@implementation MyClass
- (void)method1 {
}

- (void)method2:(id)argument {
}
@end

I would expect that in the implementation of MyClass, that the canonical decl for both methods 1 and 2 should be their definitions in MyClass and MyBaseClass. Currently, only method2 resolves to the declaration. method1 returns itself.

Kevin

-------------------------------------------------
Kevin Cathey
Department of Computer Science - College of Engineering
University of Illinois Urbana Champaign


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/a61217fa/attachment-0001.html 

From kcathey2 at illinois.edu  Tue Oct 13 23:46:17 2009
From: kcathey2 at illinois.edu (Kevin Cathey)
Date: Tue, 13 Oct 2009 23:46:17 -0500
Subject: [cfe-dev] Should ObjCMethodDecl::getCanonicalDecl search
	superclass?
In-Reply-To: <D5355513-3BC4-4878-B4CF-66C030435B76@illinois.edu>
References: <D5355513-3BC4-4878-B4CF-66C030435B76@illinois.edu>
Message-ID: <F9E39911-080C-429C-A57A-79A7BFF34BDC@illinois.edu>

Furthermore, if I have:
@interface MyClass {
}
@end

@interface MyClass ()
- (void)someOtherCategoryMethod;
@end

@implementation MyClass
- (void)someOtherCategoryMethod {
}
@end

I would expect the canonical decl for someOtherCategoryMethod in the implementation of MyClass to be the declaration in the required category.

Kevin

-------------------------------------------------
Kevin Cathey
Department of Computer Science - College of Engineering
University of Illinois Urbana Champaign


On 13 Oct 2009, at 23:28, Kevin Cathey wrote:

> Should the getCanonicalDecl method on ObjCMethodDecl also search its superclasses? For example, if I have the following:
> 
> @interface MyBaseClass <MyProtocol> {
> }
> - (void)method1;
> @end
> 
> @interface MyClass : MyBaseClass {
> }
> - (void)method2:(id)argument;
> @end
> 
> @implementation MyClass
> - (void)method1 {
> }
> 
> - (void)method2:(id)argument {
> }
> @end
> 
> I would expect that in the implementation of MyClass, that the canonical decl for both methods 1 and 2 should be their definitions in MyClass and MyBaseClass. Currently, only method2 resolves to the declaration. method1 returns itself.
> 
> Kevin
> 
> -------------------------------------------------
> Kevin Cathey
> Department of Computer Science - College of Engineering
> University of Illinois Urbana Champaign
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/b2c0d903/attachment.html 

From devlists at shadowlab.org  Wed Oct 14 00:26:23 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Wed, 14 Oct 2009 07:26:23 +0200
Subject: [cfe-dev] global variable named index
In-Reply-To: <4AD30BD5.2020200@pennware.com>
References: <F536B7C316F9474E9F7091239725AC9A03395619@CHN-CL-MAIL01.mchp-main.com>
	<A35997EA-A1F7-4330-B77D-54C65312D3EE@apple.com>
	<4AD30BD5.2020200@pennware.com>
Message-ID: <9DB27239-5364-4828-AE36-F16F173D9310@shadowlab.org>


Le 12 oct. 2009 ? 12:58, Richard Pennington a ?crit :

> Chris Lattner wrote:
>>
>> On Oct 11, 2009, at 8:55 PM, Vasudev.Negi at microchip.com
>> <mailto:Vasudev.Negi at microchip.com> wrote:
>>
>>> If I have a global variable named index, clang-cc throws an error
>>> saying redefinition of index as different kind of symbol. Why  
>>> can?t I
>>> have a variable named index?
>>>
>>
>> 'index' is the name of a function defined by the C standard library.
>> Try 'man index' on the command line.
>>
>
> 'index' was originally defined in BSD unix. It evolved into 'strchr'.
> It is not part of the C standard library, nor is it a part of POSIX
> (since POSIX.1-2008).
>


It is part of the UNIX'03 Spec

http://www.unix.org/version3/apis/t_2.html


-- Jean-Daniel






From devlists at shadowlab.org  Wed Oct 14 00:40:58 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Wed, 14 Oct 2009 07:40:58 +0200
Subject: [cfe-dev] global variable named index
In-Reply-To: <9DB27239-5364-4828-AE36-F16F173D9310@shadowlab.org>
References: <F536B7C316F9474E9F7091239725AC9A03395619@CHN-CL-MAIL01.mchp-main.com>
	<A35997EA-A1F7-4330-B77D-54C65312D3EE@apple.com>
	<4AD30BD5.2020200@pennware.com>
	<9DB27239-5364-4828-AE36-F16F173D9310@shadowlab.org>
Message-ID: <71274F31-6479-49A3-8E9B-9F4B1853328F@shadowlab.org>


Le 14 oct. 2009 ? 07:26, Jean-Daniel Dupas a ?crit :

>
> Le 12 oct. 2009 ? 12:58, Richard Pennington a ?crit :
>
>> Chris Lattner wrote:
>>>
>>> On Oct 11, 2009, at 8:55 PM, Vasudev.Negi at microchip.com
>>> <mailto:Vasudev.Negi at microchip.com> wrote:
>>>
>>>> If I have a global variable named index, clang-cc throws an error
>>>> saying redefinition of index as different kind of symbol. Why
>>>> can?t I
>>>> have a variable named index?
>>>>
>>>
>>> 'index' is the name of a function defined by the C standard library.
>>> Try 'man index' on the command line.
>>>
>>
>> 'index' was originally defined in BSD unix. It evolved into 'strchr'.
>> It is not part of the C standard library, nor is it a part of POSIX
>> (since POSIX.1-2008).
>>
>
>
> It is part of the UNIX'03 Spec
>
> http://www.unix.org/version3/apis/t_2.html
>

My bad, I wrongly interpret the function table. You're right about it  
no longer part of POSIX.



From john.thompson.jtsoftware at gmail.com  Wed Oct 14 00:53:01 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 13 Oct 2009 22:53:01 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <aad8390910131923h1cf858d3m241b1f0516c1b524@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<4AD50ED3.50007@gmail.com>
	<aad8390910131923h1cf858d3m241b1f0516c1b524@mail.gmail.com>
Message-ID: <aad8390910132253o4b6ef7dct1a626b8b033e95ed@mail.gmail.com>

Hold the fort.  After moving to VC9 and updating, the wchar_t fix breaks a
bunch of tests.  I don't know why yet  Sigh.

On Tue, Oct 13, 2009 at 7:23 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Oh.  Interesting.  I just checked VC 9.0, and they renamed the parameter.
> So I guess one solution is to just focus on VC9 for now.
>
> The wchar_t problem persists, however.  So, may I check in my proposed
> wchar_t fix?
>
> -John
>   On Tue, Oct 13, 2009 at 4:35 PM, Sean Hunt <rideau3 at gmail.com> wrote:
>
>> John Thompson wrote:
>>
>>> There is a compile error when compiling VC++'s math.h.
>>>  Apparently, the GNU extentions are still enabled by default for Windows
>>> VC++ builds, in particular "_Complex".
>>>
>>
>> _Complex is not a GNU extension; it's a C99 keyword.
>>
>> Sean Hunt
>>
>
>
>
>  --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091013/bc6d6e30/attachment.html 

From sanjiv.gupta at microchip.com  Wed Oct 14 01:00:52 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Wed, 14 Oct 2009 11:30:52 +0530
Subject: [cfe-dev] PATCH: Mangled Var name in Metadata.
In-Reply-To: <352a1fb20910131703v460ffca4n78bb3ad94ebbcdf3@mail.gmail.com>
References: <4AD30D86.5090501@microchip.com>
	<352a1fb20910131703v460ffca4n78bb3ad94ebbcdf3@mail.gmail.com>
Message-ID: <4AD56914.2040507@microchip.com>

Devang Patel wrote:
> On Mon, Oct 12, 2009 at 4:05 AM, Sanjiv Gupta
> <sanjiv.gupta at microchip.com> wrote:
>   
>> If a target has changed the variable name , it is not currently reflected in
>> Debug Info Metadata. The attached patch gets the name from Var rather than
>> the Decl, let me know if it is the right thing to do.
>>
>>     
>
> OK, go ahead.
> I'm curious, why and how would target change global variable name ?
>
> -
> Devang
>   
PIC16 does.
It converts local vars to globals and mangle their names to avoid collision.
so main () { int a; }  becomes main.a

- Sanjiv




-- 
THIS E-MAIL TRANSMISSION, AND ANY DOCUMENTS, FILES OR PREVIOUS E-MAILS
ATTACHED TO IT, IS CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE USE OF
THE NAMED RECIPIENT(S).  ANY DISSEMINATION, DISTRIBUTION OR DUPLICATION
OF THIS TRANSMISSION IS STRICTLY PROHIBITED.

If you believe you have received this e-mail in error, please notify the
Sender and delete the e-mail from your system.

DISCLAIMER OF LIABILITY:

This transmittal and any accompanying information is for suggestion only
and is provided "AS IS".  It shall not be deemed to modify Microchip's
standard warranty for its products.  It is your responsibility to ensure
that this information meets your requirements.

MICROCHIP DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED STATUTORY OR
OTHERWISE, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR
PURPOSE, NON-INFRINGEMENT, QUALITY, OR CONDITION.  MICROCHIP PROVIDES
THIS INFORMATION CONDITIONALLY UPON YOUR ACCEPTANCE OF THESE TERMS.

To the fullest extent allowed by law, Microchip's liability shall not
exceed the amount of fee, if any, that you have paid directly to
Microchip for development of this information and associated services.


From abramobagnara at tin.it  Wed Oct 14 04:56:10 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Wed, 14 Oct 2009 11:56:10 +0200
Subject: [cfe-dev] MeasureTokenLength does not works properly for comment
	tokens
Message-ID: <4AD5A03A.1050906@tin.it>


I attach the trivial patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MeasureTokenLength.patch
Type: text/x-patch
Size: 454 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091014/7602f698/attachment.bin 

From Axel.Naumann at cern.ch  Wed Oct 14 09:09:49 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Wed, 14 Oct 2009 16:09:49 +0200
Subject: [cfe-dev] lookup from AST
In-Reply-To: <4C439CEA-4593-412B-9CAC-7C0D39336BB3@apple.com>
References: <4AD47AFA.3080106@cern.ch>
	<4C439CEA-4593-412B-9CAC-7C0D39336BB3@apple.com>
Message-ID: <4AD5DBAD.1020608@cern.ch>

Hi,

the consumer is great when I want to create a map / copy of the AST 
data. But I really would like to keep the AST data inside the 
ASTContext, and only query it, e.g. starting form a type name. If I 
understand the cunsumer correctly I would have to consume the AST and 
then walk my way down the scopes, for every lookup - even though that's 
already (much better :-) implemented in Sema...

Cheers, Axel.


steve naroff wrote on 10/13/2009 07:50 PM:
> Hi Axel,
> 
> Sema is considered a transient object (whose 'output' is a well-formed 
> AST).
> 
> The design is oriented toward creating an ASTConsumer. This 'callback' 
> interface, combined with ASTContext's "get*" functions (and the 
> respective AST's) should do the trick.
> 
> Did you try this? If we are missing some functionality in the AST, let 
> us know (it is entirely possible that there is some logic that needs to 
> move from Sema->AST).
> 
> snaroff
> 
> On Oct 13, 2009, at 9:04 AM, Axel Naumann wrote:
> 
>> Hi,
>>
>> I need to access reflection gathered from some C++ code, e.g. which
>> classes are defined, what data members does class "MyClass" have. My
>> naive approach was to parse the source and query the resulting
>> ASTContext using Sema, i.e. lookup "MyClass" and walk its decls. But
>> Sema is a non-public API, which makes me wonder whether this is the
>> right approach.
>>
>> Is it?
>>
>> Cheers, Axel.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> 

From Axel.Naumann at cern.ch  Wed Oct 14 09:14:35 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Wed, 14 Oct 2009 16:14:35 +0200
Subject: [cfe-dev] Reflection from AST?
Message-ID: <4AD5DCCB.3030203@cern.ch>

Hi,

similar to my other question, but different enough to start a separate 
thread: I need to get e.g. the offsets of data members in classes, of 
base classes, and the size of a class. Would the AST be the right place? 
I cannot find that data anywhere in there - is it too "early", do I have 
to look at IR? Is there maybe an example anywhere?

Cheers, Axel.

From clattner at apple.com  Wed Oct 14 10:04:30 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Oct 2009 08:04:30 -0700
Subject: [cfe-dev] MeasureTokenLength does not works properly for
	comment	tokens
In-Reply-To: <4AD5A03A.1050906@tin.it>
References: <4AD5A03A.1050906@tin.it>
Message-ID: <ED44E6DD-3C0C-4F70-B348-5EA3803096A6@apple.com>

Thanks, applied in r84100!

On Oct 14, 2009, at 2:56 AM, Abramo Bagnara wrote:

>
> I attach the trivial patch.
> Index: lib/Lex/Lexer.cpp
> ===================================================================
> --- lib/Lex/Lexer.cpp	(revisione 84081)
> +++ lib/Lex/Lexer.cpp	(copia locale)
> @@ -238,6 +238,7 @@
>
>   // Create a lexer starting at the beginning of this token.
>   Lexer TheLexer(Loc, LangOpts, Buffer.first, StrData, Buffer.second);
> +  TheLexer.SetCommentRetentionState(true);
>   Token TheTok;
>   TheLexer.LexFromRawLexer(TheTok);
>   return TheTok.getLength();
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From dgregor at apple.com  Wed Oct 14 10:07:07 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 14 Oct 2009 08:07:07 -0700
Subject: [cfe-dev] lookup from AST
In-Reply-To: <4AD5DBAD.1020608@cern.ch>
References: <4AD47AFA.3080106@cern.ch>
	<4C439CEA-4593-412B-9CAC-7C0D39336BB3@apple.com>
	<4AD5DBAD.1020608@cern.ch>
Message-ID: <E7ED23A6-E1AF-4A6C-83D8-6751CA0A109A@apple.com>


On Oct 14, 2009, at 7:09 AM, Axel Naumann wrote:

> Hi,
>
> the consumer is great when I want to create a map / copy of the AST
> data. But I really would like to keep the AST data inside the
> ASTContext, and only query it, e.g. starting form a type name. If I
> understand the cunsumer correctly I would have to consume the AST and
> then walk my way down the scopes, for every lookup - even though  
> that's
> already (much better :-) implemented in Sema...


DeclContext::lookup will perform name lookup into a specific context  
(class, namespace, etc.), but it only looks in that context---it  
doesn't perform full C++ qualified name lookup.

The real name-lookup routines live in Sema, but there are multiple  
clients that could benefit from moving these routines into the AST.  
For qualified name lookup, it's "just" a bunch of refactoring. For  
unqualified name lookup, it's a bit tougher, since we don't actually  
maintain Scope information in the AST.

	- Doug

From dgregor at apple.com  Wed Oct 14 10:08:07 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 14 Oct 2009 08:08:07 -0700
Subject: [cfe-dev] Reflection from AST?
In-Reply-To: <4AD5DCCB.3030203@cern.ch>
References: <4AD5DCCB.3030203@cern.ch>
Message-ID: <B38A8955-2C3D-40CF-A619-04489A915BF4@apple.com>


On Oct 14, 2009, at 7:14 AM, Axel Naumann wrote:

> Hi,
>
> similar to my other question, but different enough to start a separate
> thread: I need to get e.g. the offsets of data members in classes, of
> base classes, and the size of a class. Would the AST be the right  
> place?

ASTContext::getASTRecordLayout returns the layout of a class.

	- Doug

From clattner at apple.com  Wed Oct 14 10:05:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Oct 2009 08:05:46 -0700
Subject: [cfe-dev] Reflection from AST?
In-Reply-To: <4AD5DCCB.3030203@cern.ch>
References: <4AD5DCCB.3030203@cern.ch>
Message-ID: <DD3E7500-6836-4B76-99FB-A39314CD3437@apple.com>


On Oct 14, 2009, at 7:14 AM, Axel Naumann wrote:

> Hi,
>
> similar to my other question, but different enough to start a separate
> thread: I need to get e.g. the offsets of data members in classes, of
> base classes, and the size of a class. Would the AST be the right  
> place?
> I cannot find that data anywhere in there - is it too "early", do I  
> have
> to look at IR? Is there maybe an example anywhere?

Given an ASTContext you can use Ctx.getASTRecordLayout(D) to get the  
layout information for a record decl. This is needed for C semantic  
analysis because sizeof() must be evaluatable.

-Chris

From dgregor at apple.com  Wed Oct 14 10:27:45 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 14 Oct 2009 08:27:45 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
Message-ID: <918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>


On Oct 13, 2009, at 1:02 PM, John Thompson wrote:

> There is a compile error when compiling VC++'s math.h.
>
> Apparently, the GNU extentions are still enabled by default for  
> Windows VC++ builds, in particular "_Complex".
>
> This conflicts with the parameter name in:
>
> _CRTIMP double  __cdecl _cabs(__in struct _complex _Complex);
>
> During my investigation, I tried turning off the GNU extensions when  
> the Microsoft extensions are enabled, but this is problematic with a  
> number of the tests, which use _Complex, and probably lots of other  
> places.  This raised the question in my mind as to whether the GNU  
> extensions should be enabled in this case, but I figure it's  
> probably better that way, making the compiler more flexible.

_Complex is currently a keyword in every mode. We could make it only  
be a keyword in C99 or GNU mode, then make sure that neither of these  
modes is turned on by default when Clang is built with VC++. That  
probably makes sense, since VC++ doesn't support C99 or many GNU  
extensions anyway.

We can always force tests into specific modes (turning off Microsoft  
extensions, turning on GNU extensions or C99, whatever), rather than  
trying to work around problems that are unlikely to show up in code  
that compiles with VC++.

> Therefore, one way to make this work would be to change the parser a  
> bit to detect this case, and treat the _Complex token as an  
> identifier in this case.  The error originates from line 410 of  
> DeclSpec.cpp.
> Would this be a reasonable solution?

I'd really rather not do this. We currently have one hack of this  
form, with __is_pod, because it occurs in a super-critical library  
(GNU libstdc++ <= 4.2), but we should try not to do that often. It's  
very obscure, and will lead to weird behavior. ("If I include  
<math.h>, I can no longer use complex types!")

> Actually, today there are two other errors in compiling this file,  
> related to wchar_t being defined already.  One solution is to define  
> _WCHAR_T_DEFINED for the Visual Studio targets, which will disable  
> the conflicting definition in crtdefs.h, and possibly elsewhere.   
> The enclosed patch does this, which if you will approve it, I'll  
> check it in.


What is the actual issue with the redefinition of wchar_t? Are they  
creating a typedef of wchar_t in their headers? Does the VC++ compiler  
implicitly define _WCHAR_T_DEFINED?

Regarding the patch itself: if VC++ is implicitly defining  
_WCHAR_T_DEFINED, then we should be doing so based on the Microsoft  
flag in the preprocessor-definitions, since it is effectively a  
Microsoft extension. Defining this information in the target probably  
isn't what we want.

> To make the tests less dependent on headers, I've also enclosed a  
> mathtest.patch file for eliminating the math.h inclusion in the  
> failed tests I've looked at so far.

These look good, thanks!

	- Doug

From fjahanian at apple.com  Wed Oct 14 10:44:34 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Wed, 14 Oct 2009 08:44:34 -0700
Subject: [cfe-dev] Should ObjCMethodDecl::getCanonicalDecl search
	superclass?
In-Reply-To: <F9E39911-080C-429C-A57A-79A7BFF34BDC@illinois.edu>
References: <D5355513-3BC4-4878-B4CF-66C030435B76@illinois.edu>
	<F9E39911-080C-429C-A57A-79A7BFF34BDC@illinois.edu>
Message-ID: <7CFA4979-0420-47BC-BDF7-DF0E51A6163E@apple.com>


On Oct 13, 2009, at 9:46 PM, Kevin Cathey wrote:

> Furthermore, if I have:
> @interface MyClass {
> }
> @end
>
> @interface MyClass ()
> - (void)someOtherCategoryMethod;
> @end
>
> @implementation MyClass
> - (void)someOtherCategoryMethod {
> }
> @end
>
> I would expect the canonical decl for someOtherCategoryMethod in the  
> implementation of MyClass to be the declaration in the required  
> category.

In this case,  MyClass() is an extension of class MyClass and not its  
category.

- Fariborz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091014/ff3a68f5/attachment-0001.html 

From fjahanian at apple.com  Wed Oct 14 10:50:18 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Wed, 14 Oct 2009 08:50:18 -0700
Subject: [cfe-dev] Should ObjCMethodDecl::getCanonicalDecl search
	superclass?
In-Reply-To: <D5355513-3BC4-4878-B4CF-66C030435B76@illinois.edu>
References: <D5355513-3BC4-4878-B4CF-66C030435B76@illinois.edu>
Message-ID: <BAE1810F-08E7-47A5-B295-F873A26100A8@apple.com>


On Oct 13, 2009, at 9:28 PM, Kevin Cathey wrote:

> Should the getCanonicalDecl method on ObjCMethodDecl also search its  
> superclasses? For example, if I have the following:
>
> @interface MyBaseClass <MyProtocol> {
> }
> - (void)method1;
> @end
>
> @interface MyClass : MyBaseClass {
> }
> - (void)method2:(id)argument;
> @end
>
> @implementation MyClass
> - (void)method1 {
> }
>
> - (void)method2:(id)argument {
> }
> @end
>
> I would expect that in the implementation of MyClass, that the  
> canonical decl for both methods 1 and 2 should be their definitions  
> in MyClass and MyBaseClass. Currently, only method2 resolves to the  
> declaration. method1 returns itself.

In this case you are implementing a new [MyClass method1] class which  
has no relationship to [MyBaseClass method1].
You need to provide implementation of [MyBaseClass method1] when  
@implementing MyBaseClass.

- Fariborz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091014/6c866711/attachment.html 

From wan at google.com  Wed Oct 14 15:48:23 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Wed, 14 Oct 2009 13:48:23 -0700
Subject: [cfe-dev] please review: fix for http://llvm.org/PR4407
Message-ID: <89adf3280910141348p63b05d03i5224807ec9b24b91@mail.gmail.com>

Hi,

I have a patch that fixes the first issue in http://llvm.org/PR4407 :

Clang should warn on a case value that exceeds the range of the type in
switch.
  const char ch = 'a';
  switch(ch) {
    case 1234:  // expected-warning {{overflow converting case value}}
      break;
  }

I uploaded the patch to http://codereview.appspot.com/130078/show.
Could someone review it?

This is the first time I work on clang, so please let me know if I'm
following the coding convention correctly.  Thanks,

-- 
Zhanyong

From wan at google.com  Wed Oct 14 15:51:23 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Wed, 14 Oct 2009 13:51:23 -0700
Subject: [cfe-dev] please review: fix for http://llvm.org/PR4407
In-Reply-To: <89adf3280910141348p63b05d03i5224807ec9b24b91@mail.gmail.com>
References: <89adf3280910141348p63b05d03i5224807ec9b24b91@mail.gmail.com>
Message-ID: <89adf3280910141351p593df326h6c6b2b1ca725320@mail.gmail.com>

2009/10/14 Zhanyong Wan (?x.x x) <wan at google.com>:
> Hi,
>
> I have a patch that fixes the first issue in http://llvm.org/PR4407 :
>
> Clang should warn on a case value that exceeds the range of the type in
> switch.
> ?const char ch = 'a';
> ?switch(ch) {
> ? ?case 1234: ?// expected-warning {{overflow converting case value}}
> ? ? ?break;
> ?}
>
> I uploaded the patch to http://codereview.appspot.com/130078/show.

The URL doesn't include the period in the end:
http://codereview.appspot.com/130078/show

Thanks,

> Could someone review it?
>
> This is the first time I work on clang, so please let me know if I'm
> following the coding convention correctly. ?Thanks,
>
> --
> Zhanyong
>



-- 
Zhanyong


From j.wilhelmy at arcor.de  Wed Oct 14 16:31:09 2009
From: j.wilhelmy at arcor.de (Jochen Wilhelmy)
Date: Wed, 14 Oct 2009 23:31:09 +0200
Subject: [cfe-dev] constructor notation for vector types
Message-ID: <4AD6431D.6040303@arcor.de>

Hi!

I'm new to clang and want to use it as an embedded language.
I'd like to add constructor notation to vector types that I
can write int4(1,2,3,4) instead of (int4)(1,2,3,4).
This is to have it more cg/hlsl-style or even compile existing
parts of cg/hlsl programs.
At first it's ok if it only works in c++ mode and therefore
I have to start at ActOnCXXTypeConstructExpr.
Can you give me any hints how to approach this?

Thanks & with kind regards,
Jochen


From clattner at apple.com  Wed Oct 14 17:07:32 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Oct 2009 15:07:32 -0700
Subject: [cfe-dev] constructor notation for vector types
In-Reply-To: <4AD6431D.6040303@arcor.de>
References: <4AD6431D.6040303@arcor.de>
Message-ID: <920C02C8-E88C-410C-820B-B5F5CE5AF872@apple.com>


On Oct 14, 2009, at 2:31 PM, Jochen Wilhelmy wrote:

> Hi!
>
> I'm new to clang and want to use it as an embedded language.
> I'd like to add constructor notation to vector types that I
> can write int4(1,2,3,4) instead of (int4)(1,2,3,4).
> This is to have it more cg/hlsl-style or even compile existing
> parts of cg/hlsl programs.
> At first it's ok if it only works in c++ mode and therefore
> I have to start at ActOnCXXTypeConstructExpr.
> Can you give me any hints how to approach this?

Hi Jochen,

In a language like opencl, the "opencl compiler" typically implicitly  
#includes a header that sets up a bunch of #defines, typedefs, builtin  
function declarations etc.  I think that int4 should just be a class  
defined in the header, and then everything would just work.

-Chris

From clattner at apple.com  Wed Oct 14 18:46:01 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Oct 2009 16:46:01 -0700
Subject: [cfe-dev] please review: fix for http://llvm.org/PR4407
In-Reply-To: <89adf3280910141348p63b05d03i5224807ec9b24b91@mail.gmail.com>
References: <89adf3280910141348p63b05d03i5224807ec9b24b91@mail.gmail.com>
Message-ID: <227477AB-BC7D-441D-8E2A-1397CEA1AB60@apple.com>

On Oct 14, 2009, at 1:48 PM, Zhanyong Wan (?x.x x) wrote:
> Hi,
>
> I have a patch that fixes the first issue in http://llvm.org/PR4407 :
>
> Clang should warn on a case value that exceeds the range of the type  
> in
> switch.
>  const char ch = 'a';
>  switch(ch) {
>    case 1234:  // expected-warning {{overflow converting case value}}
>      break;
>  }
>
> I uploaded the patch to http://codereview.appspot.com/130078/show.
> Could someone review it?
>
> This is the first time I work on clang, so please let me know if I'm
> following the coding convention correctly.  Thanks,

Hi Zhanyong,

Welcome to the community, thank you for tackling this!

Please attach patches to email instead of linking to codereview.   
Personally I find it a lot easier to review the patch as an attachment.

Some general points:

   const ImplicitCastExpr * const ImplicitCast

We generally don't bother declaring local variables const, something  
like this:
   const ImplicitCastExpr *ImplicitCast

... is preferred, likewise with 'const QualType', ExprBeforePromotion,  
etc.


Your test looks very nice.  Please resend with these changes, thanks!

-Chris

From wan at google.com  Wed Oct 14 19:02:56 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Wed, 14 Oct 2009 17:02:56 -0700
Subject: [cfe-dev] please review: fix for http://llvm.org/PR4407
In-Reply-To: <227477AB-BC7D-441D-8E2A-1397CEA1AB60@apple.com>
References: <89adf3280910141348p63b05d03i5224807ec9b24b91@mail.gmail.com> 
	<227477AB-BC7D-441D-8E2A-1397CEA1AB60@apple.com>
Message-ID: <89adf3280910141702x7130f9dx97875461c990c73d@mail.gmail.com>

2009/10/14 Chris Lattner <clattner at apple.com>:
> On Oct 14, 2009, at 1:48 PM, Zhanyong Wan (?x.x x) wrote:
>>
>> Hi,
>>
>> I have a patch that fixes the first issue in http://llvm.org/PR4407 :
>>
>> Clang should warn on a case value that exceeds the range of the type in
>> switch.
>> ?const char ch = 'a';
>> ?switch(ch) {
>> ? case 1234: ?// expected-warning {{overflow converting case value}}
>> ? ? break;
>> ?}
>>
>> I uploaded the patch to http://codereview.appspot.com/130078/show.
>> Could someone review it?
>>
>> This is the first time I work on clang, so please let me know if I'm
>> following the coding convention correctly. ?Thanks,
>
> Hi Zhanyong,
>
> Welcome to the community, thank you for tackling this!

Thanks!

> Please attach patches to email instead of linking to codereview. ?Personally
> I find it a lot easier to review the patch as an attachment.

Will do.  I found out that patches are supposed to be sent to
cfe-commits@, so I'll follow up on that mailing list instead.

BTW, the codereview tool lets you see more context as needed, and
makes it very easy to diff two versions of the patch.  I use it in my
open-source project (googletest) extensively and have found it really
helpful.  Therefore I'm hoping the clang team can consider using it
(maybe optionally) in the future.

> Some general points:
>
> ?const ImplicitCastExpr * const ImplicitCast
>
> We generally don't bother declaring local variables const, something like
> this:
> ?const ImplicitCastExpr *ImplicitCast
>
> ... is preferred, likewise with 'const QualType', ExprBeforePromotion, etc.

OK.  I figured out the convention from the surrounding code.  Was
trying to see if the rule could be bent. :-)

My experience is that declaring local variables as const helps the
readability and catches programmer errors.  Perhaps we can re-consider
this guideline one day, too. :-)

> Your test looks very nice. ?Please resend with these changes, thanks!

Will send to cfe-commits.  Thanks!

>
> -Chris



-- 
Zhanyong


From john.thompson.jtsoftware at gmail.com  Wed Oct 14 22:40:58 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 14 Oct 2009 20:40:58 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
Message-ID: <aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>

 Doug,


> _Complex is currently a keyword in every mode. We could make it only be a
> keyword in C99 or GNU mode, then make sure that neither of these modes is
> turned on by default when Clang is built with VC++. That probably makes
> sense, since VC++ doesn't support C99 or many GNU extensions anyway.
>
> We can always force tests into specific modes (turning off Microsoft
> extensions, turning on GNU extensions or C99, whatever), rather than trying
> to work around problems that are unlikely to show up in code that compiles
> with VC++.


How would you collectively force the tests?

I'm kinda feeling that since we're down to just 21 failing tests,
and _Complex isn't a problem with VC 9.0, we could probably punt on it for
now, and see how it goes with the rest of the tests.  But let me know if you
want me to persue this.



> What is the actual issue with the redefinition of wchar_t? Are they
> creating a typedef of wchar_t in their headers? Does the VC++ compiler
> implicitly define _WCHAR_T_DEFINED?
>

This occurs in a few headers:

#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#define _WCHAR_T_DEFINED
#endif

The enclosed wchar_t_fix2.patch seems to fix both the wchar_t issue, and
another one I ran into with VC++ headers.  I was side-tracked a bit with
errors on wchar_t I didn't understand, until I realized that wchar_t was
only a C++ keyword.

I also ran into some new errors with the VC 9.0 headers on some #pragma's.
Defining _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES avoids them, though it's a
bit of a hack.  This symbol prevents the definition of some macros, some of
which have errors, for example on __pragma statements like this:

__pragma(warning(push))

This is a Microsoft extension not currently supported, right?  It seems kind
of useful for macros.

You mentioned that the Targets.cpp was probably not the right place for the
defines, so I moved them to InitPreprocessor.cpp.  Is this the right place?

Also, could someone look at the enclosed patch for stdint.h?  This also
fixes some failing tests, since VC++ doesn't have stdint.h.  Who is point on
this?

I can check in the patches you approve.

-John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091014/baf6a9bb/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wchar_t_fix2.patch
Type: application/octet-stream
Size: 1150 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091014/baf6a9bb/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stdint.patch
Type: application/octet-stream
Size: 426 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091014/baf6a9bb/attachment-0003.obj 

From clattner at apple.com  Thu Oct 15 02:05:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 15 Oct 2009 00:05:46 -0700
Subject: [cfe-dev] Developer meeting videos up
Message-ID: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>

Hi All,

All of the videos are now up on the web page, and most of the slides  
are up (still need to get David's and Evan's slides).  Please let me  
know if you hit any problems.

You can access the content here:
http://llvm.org/devmtg/2009-10/

FYI, one room recorded a screencast and the other was recorded with a  
standalone camera.  This means that you can't see the speakers in one  
room, which is unfortunate but much better than no video :).

I want to send a huge thanks to Jason Molenda.  Not only did he  
contribute his equipment to record the event, he also collected a  
tremendous amount of the content, edited the videos, transcoded them  
and did a lot of other great work.  Getting nice videos up takes a lot  
more work than it seems, and the video quality is very high this  
year.  Thank you Jason!

-Chris

From luoyonggang at gmail.com  Thu Oct 15 02:11:22 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Thu, 15 Oct 2009 15:11:22 +0800
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <806065d90910150011q604da00ale5b74917b2028f61@mail.gmail.com>

Wow,thanks!

-- 
        ??
?
???
Yours
   sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/1f7ed74c/attachment.html 

From j.wilhelmy at arcor.de  Thu Oct 15 02:33:47 2009
From: j.wilhelmy at arcor.de (Jochen Wilhelmy)
Date: Thu, 15 Oct 2009 09:33:47 +0200
Subject: [cfe-dev] constructor notation for vector types
In-Reply-To: <920C02C8-E88C-410C-820B-B5F5CE5AF872@apple.com>
References: <4AD6431D.6040303@arcor.de>
	<920C02C8-E88C-410C-820B-B5F5CE5AF872@apple.com>
Message-ID: <4AD6D05B.4040709@arcor.de>

Hi Chris!

>
> In a language like opencl, the "opencl compiler" typically implicitly 
> #includes a header that sets up a bunch of #defines, typedefs, builtin 
> function declarations etc.  I think that int4 should just be a class 
> defined in the header, and then everything would just work.

I'm not a language expert but I think opencl does not support int4(1,2,3,4).
And how can I define int4 (or float4) as a class while at the same time it
is a built in vector type?
I would start my implicit header file with
typedef __attribute__(( ext_vector_type(4) )) float float4;

Jochen


From ladybhaal at gmail.com  Thu Oct 15 03:00:50 2009
From: ladybhaal at gmail.com (Michelle Bhaal)
Date: Thu, 15 Oct 2009 19:00:50 +1100
Subject: [cfe-dev] LLVM 84167 - Linux - undefined references
Message-ID: <5b344ead0910150100i19eddb6bn2eea026cb267e480@mail.gmail.com>

Hello.

I am compiling LLVM 84167 under Fedora 11 64 bit.  When linking llc I
get a LOT of undefined reference errors
eg:
llvm::PseudoSourceValue::getStack()
llvm::PseudoSourceValue:getFixedStack(int)
and so on.  Almost all of them are from llvm::PseudoSourceValue.

What am I missing?

Michelle

From xuzhongxing at gmail.com  Thu Oct 15 03:07:52 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Thu, 15 Oct 2009 16:07:52 +0800
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <5400aeb80910150107t79c69255u6308c86c6da21f8f@mail.gmail.com>

Thanks! I'm waiting for this.

2009/10/15 Chris Lattner <clattner at apple.com>:
> Hi All,
>
> All of the videos are now up on the web page, and most of the slides
> are up (still need to get David's and Evan's slides). ?Please let me
> know if you hit any problems.
>
> You can access the content here:
> http://llvm.org/devmtg/2009-10/
>
> FYI, one room recorded a screencast and the other was recorded with a
> standalone camera. ?This means that you can't see the speakers in one
> room, which is unfortunate but much better than no video :).
>
> I want to send a huge thanks to Jason Molenda. ?Not only did he
> contribute his equipment to record the event, he also collected a
> tremendous amount of the content, edited the videos, transcoded them
> and did a lot of other great work. ?Getting nice videos up takes a lot
> more work than it seems, and the video quality is very high this
> year. ?Thank you Jason!
>
> -Chris
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From Axel.Naumann at cern.ch  Thu Oct 15 03:22:58 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Thu, 15 Oct 2009 10:22:58 +0200
Subject: [cfe-dev] Reflection from AST?
In-Reply-To: <B38A8955-2C3D-40CF-A619-04489A915BF4@apple.com>
References: <4AD5DCCB.3030203@cern.ch>
	<B38A8955-2C3D-40CF-A619-04489A915BF4@apple.com>
Message-ID: <4AD6DBE2.10602@cern.ch>

Hi Doug and Chris,

thanks SO much! Amazing, it's all there!

Cheers, Axel.

Douglas Gregor wrote on 10/14/2009 05:08 PM:
> 
> On Oct 14, 2009, at 7:14 AM, Axel Naumann wrote:
> 
>> Hi,
>>
>> similar to my other question, but different enough to start a separate
>> thread: I need to get e.g. the offsets of data members in classes, of
>> base classes, and the size of a class. Would the AST be the right place?
> 
> ASTContext::getASTRecordLayout returns the layout of a class.
> 
>     - Doug
> 

From baldrick at free.fr  Thu Oct 15 03:49:19 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 15 Oct 2009 10:49:19 +0200
Subject: [cfe-dev] [LLVMdev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <4AD6E20F.2030301@free.fr>

> I want to send a huge thanks to Jason Molenda.  Not only did he  
> contribute his equipment to record the event, he also collected a  
> tremendous amount of the content, edited the videos, transcoded them  
> and did a lot of other great work.  Getting nice videos up takes a lot  
> more work than it seems, and the video quality is very high this  
> year.  Thank you Jason!

And his equipment actually worked, unlike some of the in-house gear!

Ciao,

Duncan.

From Axel.Naumann at cern.ch  Thu Oct 15 03:58:41 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Thu, 15 Oct 2009 10:58:41 +0200
Subject: [cfe-dev] lookup from AST
In-Reply-To: <E7ED23A6-E1AF-4A6C-83D8-6751CA0A109A@apple.com>
References: <4AD47AFA.3080106@cern.ch>
	<4C439CEA-4593-412B-9CAC-7C0D39336BB3@apple.com>
	<4AD5DBAD.1020608@cern.ch>
	<E7ED23A6-E1AF-4A6C-83D8-6751CA0A109A@apple.com>
Message-ID: <4AD6E441.6050201@cern.ch>

Hi Doug,

thanks for your help!

Douglas Gregor wrote on 10/14/2009 05:07 PM:
> DeclContext::lookup will perform name lookup into a specific context 
> (class, namespace, etc.)

Should I create an IdentifierTable and put that single name (and its 
declaring contexts) that I want to look up in there? Or is there a 
simpler way of creating a DeclarationName from a string?

 > but it only looks in that context---it doesn't
 > perform full C++ qualified name lookup.
> The real name-lookup routines live in Sema, but there are multiple 
> clients that could benefit from moving these routines into the AST. For 
> qualified name lookup, it's "just" a bunch of refactoring. 

Qualified is all I need, so having those available outside of Sema would 
be nice. Should I give it a try and suggest a patch? If so, should I 
simply replace DeclContext::lookup by what Sema::LookupQualifiedName 
currently does? I believe given qualified lookup in DeclContext we 
wouldn't need DeclContext::lookup anymore.

Cheers, Axel.

From spellegrini at dps.uibk.ac.at  Thu Oct 15 04:00:36 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Thu, 15 Oct 2009 11:00:36 +0200
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <4AD6E4B4.4050209@dps.uibk.ac.at>

Chris Lattner wrote:
> Hi All,
>
> All of the videos are now up on the web page, and most of the slides  
> are up (still need to get David's and Evan's slides).  Please let me  
> know if you hit any problems.
>
> You can access the content here:
> http://llvm.org/devmtg/2009-10/
>   
Is there any chance to see the Clang-related slides?
i.e. State of Clang and OpenCL?

cheers, Simone
**
> FYI, one room recorded a screencast and the other was recorded with a  
> standalone camera.  This means that you can't see the speakers in one  
> room, which is unfortunate but much better than no video :).
>
> I want to send a huge thanks to Jason Molenda.  Not only did he  
> contribute his equipment to record the event, he also collected a  
> tremendous amount of the content, edited the videos, transcoded them  
> and did a lot of other great work.  Getting nice videos up takes a lot  
> more work than it seems, and the video quality is very high this  
> year.  Thank you Jason!
>
> -Chris
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>   


From ladybhaal at gmail.com  Thu Oct 15 05:43:18 2009
From: ladybhaal at gmail.com (Michelle Bhaal)
Date: Thu, 15 Oct 2009 21:43:18 +1100
Subject: [cfe-dev] LLVM 84167 - Linux - undefined references
In-Reply-To: <5b344ead0910150100i19eddb6bn2eea026cb267e480@mail.gmail.com>
References: <5b344ead0910150100i19eddb6bn2eea026cb267e480@mail.gmail.com>
Message-ID: <5b344ead0910150343w4f55d90an92516553bf04f9af@mail.gmail.com>

Further to this, when Regenerating LibDeps.txt.tmp I get the following errors:
/usr/bin/nm: PostRASchedulerList.o: File format not recognized

As well for
PreAllocSplitting.o
PsuedoSourceValue.o
PostRASchedulerList.o
PreAllocSplitting.o
PsuedoSourceValue.o

This covers all the undefined references.

Why is the file format not recognized?

Michelle (now on 84180)


2009/10/15 Michelle Bhaal <ladybhaal at gmail.com>:
> Hello.
>
> I am compiling LLVM 84167 under Fedora 11 64 bit. ?When linking llc I
> get a LOT of undefined reference errors
> eg:
> llvm::PseudoSourceValue::getStack()
> llvm::PseudoSourceValue:getFixedStack(int)
> and so on. ?Almost all of them are from llvm::PseudoSourceValue.
>
> What am I missing?
>
> Michelle
>


From Axel.Naumann at cern.ch  Thu Oct 15 08:06:37 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Thu, 15 Oct 2009 15:06:37 +0200
Subject: [cfe-dev] lookup from AST
In-Reply-To: <4AD6E441.6050201@cern.ch>
References: <4AD47AFA.3080106@cern.ch>	<4C439CEA-4593-412B-9CAC-7C0D39336BB3@apple.com>	<4AD5DBAD.1020608@cern.ch>	<E7ED23A6-E1AF-4A6C-83D8-6751CA0A109A@apple.com>
	<4AD6E441.6050201@cern.ch>
Message-ID: <4AD71E5D.1010405@cern.ch>

Hi,

progress, but not enough:

Axel Naumann wrote on 10/15/2009 10:58 AM:
> Should I create an IdentifierTable and put that single name (and its 
> declaring contexts) that I want to look up in there? Or is there a 
> simpler way of creating a DeclarationName from a string?

of course this is the wrong approach; I should first lex the string. But 
building a full blown preprocessor every time I need to lex a string 
like "nsp::class" looks a bit heavy. Is there a shortcut? Is it 
Preprocessor::CreateString()?

And the offer below still stands ;-)

Cheers, Axel.

>  > but it only looks in that context---it doesn't
>  > perform full C++ qualified name lookup.
>> The real name-lookup routines live in Sema, but there are multiple 
>> clients that could benefit from moving these routines into the AST. For 
>> qualified name lookup, it's "just" a bunch of refactoring. 
> 
> Qualified is all I need, so having those available outside of Sema would 
> be nice. Should I give it a try and suggest a patch? If so, should I 
> simply replace DeclContext::lookup by what Sema::LookupQualifiedName 
> currently does? I believe given qualified lookup in DeclContext we 
> wouldn't need DeclContext::lookup anymore.
> 
> Cheers, Axel.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 

From chobbs at qnx.com  Thu Oct 15 08:12:31 2009
From: chobbs at qnx.com (Chris Hobbs)
Date: Thu, 15 Oct 2009 09:12:31 -0400
Subject: [cfe-dev] Newbie: Build Problem
Message-ID: <1255612351.6507.245.camel@chobbs-laptop>

Carefully following the instructions on the clang web page:

svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm/tools/
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
cd ..
./configure
make

I encountered the following build errors:

make[4]: Entering directory
`/home/chobbs/clang/llvm/tools/clang/lib/Frontend'
llvm[4]: Compiling TextDiagnosticPrinter.cpp for Debug build
TextDiagnosticPrinter.cpp: In member function ?void
clang::TextDiagnosticPrinter::EmitCaretDiagnostic(clang::SourceLocation,
clang::SourceRange*, unsigned int, clang::SourceManager&, const
clang::CodeModificationHint*, unsigned int, unsigned int)?:
TextDiagnosticPrinter.cpp:415: error: no matching function for call to
?llvm::raw_ostream::changeColor(const llvm::raw_ostream::Colors&, bool)?
/home/chobbs/clang/llvm/include/llvm/Support/raw_ostream.h:236: note:
candidates are: virtual llvm::raw_ostream&
llvm::raw_ostream::changeColor(llvm::raw_ostream::Colors, bool, bool)
TextDiagnosticPrinter.cpp:423: error: no matching function for call to
?llvm::raw_ostream::changeColor(const llvm::raw_ostream::Colors&, bool)?
/home/chobbs/clang/llvm/include/llvm/Support/raw_ostream.h:236: note:
candidates are: virtual llvm::raw_ostream&
llvm::raw_ostream::changeColor(llvm::raw_ostream::Colors, bool, bool)
TextDiagnosticPrinter.cpp: In member function ?virtual void
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::Diagnostic::Level,
const clang::DiagnosticInfo&)?:
TextDiagnosticPrinter.cpp:626: error: no matching function for call to
?llvm::raw_ostream::changeColor(const llvm::raw_ostream::Colors&, bool)?
/home/chobbs/clang/llvm/include/llvm/Support/raw_ostream.h:236: note:
candidates are: virtual llvm::raw_ostream&
llvm::raw_ostream::changeColor(llvm::raw_ostream::Colors, bool, bool)

etc.

In case it's important, here is the first section of configure.log:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

==========begin config.log

It was created by llvm configure 2.7svn, which was
generated by GNU Autoconf 2.60.  Invocation command line was

  $ ./configure 

## --------- ##
## Platform. ##
## --------- ##

hostname = chobbs-laptop
uname -m = i686
uname -r = 2.6.24-24-generic
uname -s = Linux
uname -v = #1 SMP Fri Sep 18 16:49:39 UTC 2009

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /opt/qnx640/host/linux/x86/usr/bin
PATH: /etc/qnx/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2154: checking build system type
configure:2172: result: i686-pc-linux-gnu
configure:2194: checking host system type
configure:2209: result: i686-pc-linux-gnu
configure:2231: checking target system type
configure:2246: result: i686-pc-linux-gnu
configure:2275: checking type of operating system we're going to host on
configure:2378: result: Linux
configure:2381: checking type of operating system we're going to target
configure:2425: result: Linux
configure:2471: checking target architecture
configure:2492: result: x86
configure:2558: checking for gcc
configure:2574: found /usr/bin/gcc
configure:2585: result: gcc
configure:2823: checking for C compiler version
configure:2830: gcc --version >&5
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

===========etc. End of first section of config.log

I have scanned the mailing lists looking for any reference to this
problem without success (although I may easily have missed something).
It doesn't appear just to be a misspelling of "Colour" either :-)

Any thoughts?

-- 
Chris Hobbs (chobbs at qnx.com) 
QNX Software Systems
175 Terence Matthews Crescent
Ottawa, Ontario, Canada K2M 1W8

Skype: cwlhobbs                         
PSTN:  +1 613 591-0931          


From dgregor at apple.com  Thu Oct 15 08:26:26 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 15 Oct 2009 06:26:26 -0700
Subject: [cfe-dev] Newbie: Build Problem
In-Reply-To: <1255612351.6507.245.camel@chobbs-laptop>
References: <1255612351.6507.245.camel@chobbs-laptop>
Message-ID: <AA6E4C90-B696-4EBE-8EDB-EA01F5DF2029@apple.com>


On Oct 15, 2009, at 6:12 AM, Chris Hobbs wrote:

> Carefully following the instructions on the clang web page:
>
> svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
> cd llvm/tools/
> svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
> cd ..
> ./configure
> make

Try running "svn up" in both "llvm" and "llvm/tools/clang", then  
building again. Someone accidentally broke the Clang build with a  
change to LLVM, but it's fixed now.

	- Doug


From chobbs at qnx.com  Thu Oct 15 08:32:38 2009
From: chobbs at qnx.com (Chris Hobbs)
Date: Thu, 15 Oct 2009 09:32:38 -0400
Subject: [cfe-dev] Newbie: Build Problem
In-Reply-To: <AA6E4C90-B696-4EBE-8EDB-EA01F5DF2029@apple.com>
References: <1255612351.6507.245.camel@chobbs-laptop>
	<AA6E4C90-B696-4EBE-8EDB-EA01F5DF2029@apple.com>
Message-ID: <1255613558.6507.247.camel@chobbs-laptop>

On Thu, 2009-10-15 at 06:26 -0700, Douglas Gregor wrote:
> On Oct 15, 2009, at 6:12 AM, Chris Hobbs wrote:
> 
> > Carefully following the instructions on the clang web page:
> >
> > svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
> > cd llvm/tools/
> > svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
> > cd ..
> > ./configure
> > make
> 
> Try running "svn up" in both "llvm" and "llvm/tools/clang", then  
> building again. Someone accidentally broke the Clang build with a  
> change to LLVM, but it's fixed now.
> 
> 	- Doug

Looks good. Many thanks for the prompt response.

Chris

> 
-- 
Chris Hobbs (chobbs at qnx.com) 
QNX Software Systems
175 Terence Matthews Crescent
Ottawa, Ontario, Canada K2M 1W8

Skype: cwlhobbs                         
PSTN:  +1 613 591-0931          

From john.thompson.jtsoftware at gmail.com  Thu Oct 15 09:44:45 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 15 Oct 2009 07:44:45 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
Message-ID: <aad8390910150744l5f5689f2n979b1a284912258b@mail.gmail.com>

I'm terribly sorry!  In builtins.c I accidentally commited some experimental
changes I added after making the patch, making that test fail.  I've
commited the fix.

-John

On Wed, Oct 14, 2009 at 8:40 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

>  Doug,
>
>
>> _Complex is currently a keyword in every mode. We could make it only be a
>> keyword in C99 or GNU mode, then make sure that neither of these modes is
>> turned on by default when Clang is built with VC++. That probably makes
>> sense, since VC++ doesn't support C99 or many GNU extensions anyway.
>>
>> We can always force tests into specific modes (turning off Microsoft
>> extensions, turning on GNU extensions or C99, whatever), rather than trying
>> to work around problems that are unlikely to show up in code that compiles
>> with VC++.
>
>
> How would you collectively force the tests?
>
> I'm kinda feeling that since we're down to just 21 failing tests,
> and _Complex isn't a problem with VC 9.0, we could probably punt on it for
> now, and see how it goes with the rest of the tests.  But let me know if you
> want me to persue this.
>
>
>
>> What is the actual issue with the redefinition of wchar_t? Are they
>> creating a typedef of wchar_t in their headers? Does the VC++ compiler
>> implicitly define _WCHAR_T_DEFINED?
>>
>
> This occurs in a few headers:
>
> #ifndef _WCHAR_T_DEFINED
> typedef unsigned short wchar_t;
> #define _WCHAR_T_DEFINED
> #endif
>
> The enclosed wchar_t_fix2.patch seems to fix both the wchar_t issue, and
> another one I ran into with VC++ headers.  I was side-tracked a bit with
> errors on wchar_t I didn't understand, until I realized that wchar_t was
> only a C++ keyword.
>
> I also ran into some new errors with the VC 9.0 headers on some #pragma's.
> Defining _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES avoids them, though it's a
> bit of a hack.  This symbol prevents the definition of some macros, some of
> which have errors, for example on __pragma statements like this:
>
> __pragma(warning(push))
>
> This is a Microsoft extension not currently supported, right?  It seems
> kind of useful for macros.
>
> You mentioned that the Targets.cpp was probably not the right place for the
> defines, so I moved them to InitPreprocessor.cpp.  Is this the right place?
>
> Also, could someone look at the enclosed patch for stdint.h?  This also
> fixes some failing tests, since VC++ doesn't have stdint.h.  Who is point on
> this?
>
> I can check in the patches you approve.
>
> -John
>
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/0bb2e11d/attachment.html 

From anton at korobeynikov.info  Thu Oct 15 10:29:00 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Thu, 15 Oct 2009 19:29:00 +0400
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>

Hi, Chris

> All of the videos are now up on the web page, and most of the slides
> are up (still need to get David's and Evan's slides). ?Please let me
> know if you hit any problems.
First of all, thanks a lot about all stuff with videos & slides posting.

I'm a bit curious: is there any reason why are other slides / videos
not available (it seems that the ones missing are from Apple folks)?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From john.thompson.jtsoftware at gmail.com  Thu Oct 15 10:42:03 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 15 Oct 2009 08:42:03 -0700
Subject: [cfe-dev] CodeGen/statements.c: Don't understand test and its
	failure
Message-ID: <aad8390910150842q5c91b383r4e8a117a21d06f4e@mail.gmail.com>

On Windows, the CodeGen/statements.c test fails, apparently because of this
error:

3><stdin>:23:17: error: initializer element is not a compile-time constant
3>static long x = &&bar - &&baz;
3>                ^~~~~~~~~~~~~
First, what does a unary "&&" do on a variable?  Address of an address?  It
doesn't seem to make sense.

Second, why would it result in an error in VC++-built Clang, but not on
other platforms?  (I tried using other target triples, but there was no
change.)

I know I'll probably have to debug it, but understanding the first might
help.

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/577f29ad/attachment-0001.html 

From clattner at apple.com  Thu Oct 15 10:45:07 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 15 Oct 2009 08:45:07 -0700
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
Message-ID: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>

On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote:
> Hi, Chris
>
>> All of the videos are now up on the web page, and most of the slides
>> are up (still need to get David's and Evan's slides).  Please let me
>> know if you hit any problems.
> First of all, thanks a lot about all stuff with videos & slides  
> posting.
>
> I'm a bit curious: is there any reason why are other slides / videos
> not available (it seems that the ones missing are from Apple folks)?

Unfortunately, we found out at the last minute that Apple has a rule  
which prevents its engineers from giving video taped talks or  
distributing slides.  We will hold onto the video and slide assets in  
case this rule changes in the future.

-Chris

From clattner at apple.com  Thu Oct 15 10:49:27 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 15 Oct 2009 08:49:27 -0700
Subject: [cfe-dev] lookup from AST
In-Reply-To: <4AD71E5D.1010405@cern.ch>
References: <4AD47AFA.3080106@cern.ch>
	<4C439CEA-4593-412B-9CAC-7C0D39336BB3@apple.com>
	<4AD5DBAD.1020608@cern.ch>
	<E7ED23A6-E1AF-4A6C-83D8-6751CA0A109A@apple.com>
	<4AD6E441.6050201@cern.ch> <4AD71E5D.1010405@cern.ch>
Message-ID: <A14E04AB-63F2-4FBE-97EB-84011C197968@apple.com>


On Oct 15, 2009, at 6:06 AM, Axel Naumann wrote:

> Hi,
>
> progress, but not enough:
>
> Axel Naumann wrote on 10/15/2009 10:58 AM:
>> Should I create an IdentifierTable and put that single name (and its
>> declaring contexts) that I want to look up in there? Or is there a
>> simpler way of creating a DeclarationName from a string?
>
> of course this is the wrong approach; I should first lex the string.  
> But
> building a full blown preprocessor every time I need to lex a string
> like "nsp::class" looks a bit heavy. Is there a shortcut? Is it
> Preprocessor::CreateString()?

If you have an ASTContext, you should be able to get to the identifier  
table it refers to.  Based on that, you can use Table->get("foo") to  
get a uniqued identifierinfo*.

-Chris


From clattner at apple.com  Thu Oct 15 10:50:31 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 15 Oct 2009 08:50:31 -0700
Subject: [cfe-dev] CodeGen/statements.c: Don't understand test and
	its	failure
In-Reply-To: <aad8390910150842q5c91b383r4e8a117a21d06f4e@mail.gmail.com>
References: <aad8390910150842q5c91b383r4e8a117a21d06f4e@mail.gmail.com>
Message-ID: <9BCF98C5-78B5-4808-A8C2-F6C0C55DBFDB@apple.com>


On Oct 15, 2009, at 8:42 AM, John Thompson wrote:

> On Windows, the CodeGen/statements.c test fails, apparently because  
> of this error:
>
> 3><stdin>:23:17: error: initializer element is not a compile-time  
> constant
> 3>static long x = &&bar - &&baz;
> 3>                ^~~~~~~~~~~~~
> First, what does a unary "&&" do on a variable?  Address of an  
> address?  It doesn't seem to make sense.
>
> Second, why would it result in an error in VC++-built Clang, but not  
> on other platforms?  (I tried using other target triples, but there  
> was no change.)
>
> I know I'll probably have to debug it, but understanding the first  
> might help.

This is the GNU address of a label extension.  Can you remove the  
'static' (which will allow it to parse) and paste what clang-cc -ast- 
dump shows for that statement?

-Chris

From clattner at apple.com  Thu Oct 15 10:57:01 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 15 Oct 2009 08:57:01 -0700
Subject: [cfe-dev] LLVM 84167 - Linux - undefined references
In-Reply-To: <5b344ead0910150100i19eddb6bn2eea026cb267e480@mail.gmail.com>
References: <5b344ead0910150100i19eddb6bn2eea026cb267e480@mail.gmail.com>
Message-ID: <1C01745A-6D56-40E0-B14B-94BF384CE409@apple.com>


On Oct 15, 2009, at 1:00 AM, Michelle Bhaal wrote:

> Hello.
>
> I am compiling LLVM 84167 under Fedora 11 64 bit.  When linking llc I
> get a LOT of undefined reference errors
> eg:
> llvm::PseudoSourceValue::getStack()
> llvm::PseudoSourceValue:getFixedStack(int)
> and so on.  Almost all of them are from llvm::PseudoSourceValue.

Hi Michelle,

Are your llvm and clang trees both the same revision number?  Have you  
tried a clean build?  Are you using make or cmake?

-Chris

From john.thompson.jtsoftware at gmail.com  Thu Oct 15 11:05:25 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 15 Oct 2009 09:05:25 -0700
Subject: [cfe-dev] Fwd: CodeGen/statements.c: Don't understand test and its
	failure
In-Reply-To: <aad8390910150859j5602ebbag49e6d081f39ae0f2@mail.gmail.com>
References: <aad8390910150842q5c91b383r4e8a117a21d06f4e@mail.gmail.com>
	<9BCF98C5-78B5-4808-A8C2-F6C0C55DBFDB@apple.com>
	<aad8390910150859j5602ebbag49e6d081f39ae0f2@mail.gmail.com>
Message-ID: <aad8390910150905x4ffafd65x1ac99ffce32df63b@mail.gmail.com>

Sorry Chris, I meant to send this to the list.

---------- Forwarded message ----------
From: John Thompson <john.thompson.jtsoftware at gmail.com>
Date: Thu, Oct 15, 2009 at 8:59 AM
Subject: Re: [cfe-dev] CodeGen/statements.c: Don't understand test and its
failure


  This is the GNU address of a label extension.  Can you remove the 'static'
> (which will allow it to parse) and paste what clang-cc -ast-dump shows for
> that statement?
>


Thanks.  Here it is:

CodeGen/statements.c:5:6: warning: integer constant is too large for its
type
case 111111111111111111111111111111111111111:
     ^
CodeGen/statements.c:5:6: warning: overflow converting case value to switch
condition type (11011968431394943431 to 18446744072755114439)
CodeGen/statements.c:11:15: warning: non-void function 'test2' should return
a value
int test2() { return; }
              ^
CodeGen/statements.c:12:16: warning: void function 'test3' should not return
a value
void test3() { return 4; }
               ^      ~
CodeGen/statements.c:24:17: warning: incompatible pointer to integer
conversion initializing 'void *', expected 'long'
static long y = &&baz;
                ^~~~~
CodeGen/statements.c:28:10: warning: incompatible integer to pointer
conversion passing 'long', expected 'void *'
    goto *y;
         ^~
CodeGen/statements.c:30:8: warning: incompatible integer to pointer
conversion passing 'long', expected 'void *'
  goto *x;
       ^~
CodeGen/statements.c:25:3: warning: expression result unused
  &&bing;
  ^~~~~~
CodeGen/statements.c:26:3: warning: expression result unused
  &&blong;
  ^~~~~~~
CodeGen/statements.c:34:31: warning: incompatible integer to pointer
conversion passing 'long long', expected 'void *'
int test5(long long b) { goto *b; }
                              ^~
typedef char *__builtin_va_list;
void test1(int x)

int bar();
int test2()

void test3()

void test4()

int test5(long long b)

(CompoundStmt 029AF2D8 <CodeGen/statements.c:3:19, line:8:1>
  (SwitchStmt 029AEC98 <line:4:1, line:7:1>
    (DeclRefExpr 029B0570 <line:4:9> 'int' ParmVar='x' 029B0508)
    (CompoundStmt 029AF120 <col:12, line:7:1>
      (CaseStmt 029AEE48 <line:5:1, line:6:5>
        (CallExpr 029AF0A8 <col:1, col:5> 'int'
          (ImplicitCastExpr 029AF060 <col:1> 'int (*)()'
<FunctionToPointerDecay>
            (DeclRefExpr 029AEFD0 <col:1> 'int ()' FunctionDecl='bar'
029AEF40)))
        (ImplicitCastExpr 029AF1E8 <line:5:6> 'int' <Unknown>
          (IntegerLiteral 029AEDF0 <col:6> 'unsigned long long'
11011968431394943431))
        <<<NULL>>>))))
(CompoundStmt 029AF3F0 <CodeGen/statements.c:11:13, col:23>
  (ReturnStmt 029AF3B0 <col:15>))
(CompoundStmt 029AF638 <CodeGen/statements.c:12:14, col:26>
  (ReturnStmt 029AF5F8 <col:16, col:23>
    (IntegerLiteral 029AF5A0 <col:23> 'int' 4)))
(CompoundStmt 029AF740 <CodeGen/statements.c:15:14, line:31:1>
  (LabelStmt 029B7068 <line:16:1, line:20:2> 'bar'
    (LabelStmt 029B7028 <line:17:1, line:20:2> 'baz'
      (LabelStmt 029AF7C8 <line:18:1, line:20:2> 'blong'
        (LabelStmt 029AF788 <line:19:1, line:20:2> 'bing'
          (NullStmt 029AF230 <col:2>)))))
  (DeclStmt 029B7238 <line:23:1, col:23>
    029B70A8 "long x =
      (ImplicitCastExpr 029B71F0 <col:10, col:20> 'long' <Unknown>
        (BinaryOperator 029B71A0 <col:10, col:20> 'int' '-'
          (AddrLabelExpr 029B7110 <col:10, col:12> 'void *' bar 029B7068)
          (AddrLabelExpr 029B7158 <col:18, col:20> 'void *' baz 029B7028)))"
  (DeclStmt 029B7370 <line:24:1, col:22>
    029B7278 "static long y =
      (ImplicitCastExpr 029B7328 <col:17, col:19> 'long' <Unknown>
        (AddrLabelExpr 029B72E0 <col:17, col:19> 'void *' baz 029B7028))"
  (AddrLabelExpr 029B73B0 <line:25:3, col:5> 'void *' bing 029AF788)
  (AddrLabelExpr 029B73F8 <line:26:3, col:5> 'void *' blong 029AF7C8)
  (IfStmt 029B7558 <line:27:3, line:28:11>
    (DeclRefExpr 029B7440 <line:27:7> 'long' Var='y' 029B7278)
    (IndirectGotoStmt 029B7518 <line:28:5, col:11>
      (ImplicitCastExpr 029B74D0 <col:11> 'void *' <Unknown>
        (DeclRefExpr 029B7488 <col:11> 'long' Var='y' 029B7278)))
    <<<NULL>>>)
  (IndirectGotoStmt 029B7630 <line:30:3, col:9>
    (ImplicitCastExpr 029B75E8 <col:9> 'void *' <Unknown>
      (DeclRefExpr 029B75A0 <col:9> 'long' Var='x' 029B70A8))))
(CompoundStmt 029AE428 <CodeGen/statements.c:34:24, col:35>
  (IndirectGotoStmt 029B7918 <col:26, col:32>
    (ImplicitCastExpr 029B78D0 <col:32> 'void *' <Unknown>
      (DeclRefExpr 029B7888 <col:32> 'long long' ParmVar='b' 029B7708))))
10 diagnostics generated.


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com




-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/88699dff/attachment.html 

From dgregor at apple.com  Thu Oct 15 11:54:36 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 15 Oct 2009 09:54:36 -0700
Subject: [cfe-dev] constructor notation for vector types
In-Reply-To: <4AD6431D.6040303@arcor.de>
References: <4AD6431D.6040303@arcor.de>
Message-ID: <71B2ED12-DC29-4033-BD87-A7D2B38BF1C0@apple.com>


On Oct 14, 2009, at 2:31 PM, Jochen Wilhelmy wrote:

> Hi!
>
> I'm new to clang and want to use it as an embedded language.
> I'd like to add constructor notation to vector types that I
> can write int4(1,2,3,4) instead of (int4)(1,2,3,4).
> This is to have it more cg/hlsl-style or even compile existing
> parts of cg/hlsl programs.
> At first it's ok if it only works in c++ mode and therefore
> I have to start at ActOnCXXTypeConstructExpr.
> Can you give me any hints how to approach this?


Look through the logic in ActOnCXXConstructExpr. You should be able to  
add another "if" that looks for a vector type, then find the code  
where we handle (int4)(1, 2, 3, 4) and unify the logic for those two.

	- Doug

From juanc.martinez.santos at gmail.com  Thu Oct 15 11:58:56 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Thu, 15 Oct 2009 12:58:56 -0400
Subject: [cfe-dev] Clang as back-end
Message-ID: <d17b77a40910150958q1e8d4deai6a87b07779aaa4d5@mail.gmail.com>

Hello,

I am interesting in doing dynamic information flow tracking - DIFT. In the
process, I need to add a new attribute for each variable used in the
program, and also I need to modify the way how the variables are aggregate
(on BBS | heap | stack of an x86 architecture). My concern is if Clang could
be the tool that I need.

>From the "get started" guide, I see that (1) clang is the front-end. (2)
LLVM is used to optimize the IR, but I didn't see what is the back-end. Is
clang also the back-end? or this option is open?

BTW. Where I can more details about "addspace" instruction. I found some
piece of information in several documents (LLVM and Clang) but I didn't see
any document or section that talk about it. And the last question: is
"addrspace" instruction just for global variables?
 Thanks in advance,

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/c5749612/attachment.html 

From dgregor at apple.com  Thu Oct 15 12:09:09 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 15 Oct 2009 10:09:09 -0700
Subject: [cfe-dev] Clang as back-end
In-Reply-To: <d17b77a40910150958q1e8d4deai6a87b07779aaa4d5@mail.gmail.com>
References: <d17b77a40910150958q1e8d4deai6a87b07779aaa4d5@mail.gmail.com>
Message-ID: <BE0FFB47-A15C-48FA-BF1F-32DB24CC5CB1@apple.com>


On Oct 15, 2009, at 9:58 AM, Juan Carlos Martinez Santos wrote:
> I am interesting in doing dynamic information flow tracking - DIFT.  
> In the process, I need to add a new attribute for each variable used  
> in the program, and also I need to modify the way how the variables  
> are aggregate (on BBS | heap | stack of an x86 architecture). My  
> concern is if Clang could be the tool that I need.


> From the "get started" guide, I see that (1) clang is the front-end.  
> (2) LLVM is used to optimize the IR, but I didn't see what is the  
> back-end. Is clang also the back-end? or this option is open?

Clang is the front end. It has a "CodeGen" module that lowers to the  
LLVM optimizer and back-end. Clang's abstract syntax trees should be  
generic enough that one could generate IR for a different back-end,  
but to my knowledge nobody has tried that.


> BTW. Where I can more details about "addspace" instruction. I found  
> some piece of information in several documents (LLVM and Clang) but  
> I didn't see any document or section that talk about it. And the  
> last question: is "addrspace" instruction just for global variables?


It's not an instruction, but a qualifier that specifies which address  
space something resides in. It can be applied to globals and the types  
referenced by pointers. The intent is to model the named address  
spaces of the C Embedded TR (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1169.pdf 
); the specific syntax we've chosen is shown here:

	http://clang.llvm.org/docs/LanguageExtensions.html#x86-specific

	- Doug

From dimitry at andric.com  Thu Oct 15 13:15:44 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Thu, 15 Oct 2009 20:15:44 +0200
Subject: [cfe-dev] Executable search on MinGW32
Message-ID: <4AD766D0.6080105@andric.com>

Hi,

I have been trying to get clang working with MinGW32, and ran into a
number of minor problems.  One of them is the way executables (e.g.
clang-cc, as, ld) are searched, usually with GetProgramPath().  On
Windows, these executables need to have ".exe" appended to be found.

This needed changes in both clang and llvm.  Please see the attached
diffs.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: clang-findexe.diff
Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/ef5c82d6/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: llvm-findexe.diff
Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/ef5c82d6/attachment-0001.pl 

From juanc.martinez.santos at gmail.com  Thu Oct 15 15:54:21 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Thu, 15 Oct 2009 16:54:21 -0400
Subject: [cfe-dev] Clang as back-end
In-Reply-To: <EF9E8F3C-FE54-4C16-95DC-FF5CF4328D9A@apple.com>
References: <d17b77a40910150958q1e8d4deai6a87b07779aaa4d5@mail.gmail.com>
	<BE0FFB47-A15C-48FA-BF1F-32DB24CC5CB1@apple.com>
	<d17b77a40910151232g25d44082vec28aff02ae42bf4@mail.gmail.com>
	<EF9E8F3C-FE54-4C16-95DC-FF5CF4328D9A@apple.com>
Message-ID: <d17b77a40910151354t1495b11bpe64d3bc745d6eee5@mail.gmail.com>

Hello,

 I tried to test the qualifier address_space so I used the example in the
web site: http://clang.llvm.org/docs/LanguageExtensions.html#x86-specific

I used <clang-cc + llvm-as + llc>, and I got the expected result; however,
when I tried to generated the executable, I got the bellow error.

Any idea that what can be wrong.

Thanks in advance,

Juan Carlos

***************
*** Result ***
***************
~/test$ <8 at emperor:~/test$> clang addrspace2.c -o addrspace2.exe -v
clang version 1.1 (trunk 83900)
Target: i386-pc-linux-gnu
Thread model: posix
 "/home/jcmartin78/llvm/Debug/bin/clang-cc" -triple i386-pc-linux-gnu -S
-disable-free -main-file-name addrspace2.c --relocation-model static
--disable-fp-elim --unwind-tables=0 --mcpu=pentium4 --fmath-errno=1 -v
-fexceptions=0 -fdiagnostics-show-option -o /tmp/cc-3YHq3X.s -x c
addrspace2.c
clang-cc version 1.1 based upon llvm 2.7svn hosted on i386-pc-linux-gnu
ignoring nonexistent directory "/System/Library/Frameworks"
ignoring nonexistent directory "/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /home/jcmartin78/llvm/Debug/lib/clang/1.1/include
 /usr/local/include
 /usr/include
End of search list.
 "/usr/bin/gcc" -v -c -m32 -o /tmp/cc-Jp3bRb.o -x assembler /tmp/cc-3YHq3X.s
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
COLLECT_GCC_OPTIONS='-v' '-c' '-m32' '-o' '/tmp/cc-Jp3bRb.o'
'-mtune=generic'
 as -V -Qy --32 -o /tmp/cc-Jp3bRb.o /tmp/cc-3YHq3X.s
GNU assembler version 2.19.1 (i486-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.19.1
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-m32' '-o' '/tmp/cc-Jp3bRb.o'
'-mtune=generic'
 "/usr/bin/gcc" -v -m32 -o addrspace2.exe /tmp/cc-Jp3bRb.o
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'addrspace2.exe' '-mtune=generic'
 /usr/lib/gcc/i486-linux-gnu/4.3.3/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o addrspace2.exe -z
relro /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.3.3/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3
-L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../..
/tmp/cc-Jp3bRb.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i486-linux-gnu/4.3.3/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crtn.o
/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o: In function
`_start':
/build/buildd/glibc-2.9/csu/../sysdeps/i386/elf/start.S:115: undefined
reference to `main'
collect2: ld returned 1 exit status
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
***************************

On Thu, Oct 15, 2009 at 3:47 PM, Douglas Gregor <dgregor at apple.com> wrote:

> Please always reply to the cfe-dev mailing list.
>
> On Oct 15, 2009, at 12:32 PM, Juan Carlos Martinez Santos wrote:
>
> Hello Douglas,
>>
>> I see that clang support address space #256 and #257. What about others?
>>
>
> Clang just passes the address space through to LLVM; it doesn't care what
> address space number you use.
>
> For the technical report I read that the address space is supported in C
>> language because some architectures support multiple-spaces. Is x86 one of
>> them?
>>
>
> I don't know what happens to address spaces on x86.
>
> How I can specify customs address spaces? This parts bellows to the
>> back-end, doesn't?
>>
>
> Yes, it's all handled in the back-end. For custom address spaces, just use
> a different address space number.
>
>        - Doug
>



-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/715df72c/attachment.html 

From skabet at gmail.com  Thu Oct 15 16:09:22 2009
From: skabet at gmail.com (Anders Johnsen)
Date: Thu, 15 Oct 2009 23:09:22 +0200
Subject: [cfe-dev] Clang as back-end
In-Reply-To: <d17b77a40910151354t1495b11bpe64d3bc745d6eee5@mail.gmail.com>
References: <d17b77a40910150958q1e8d4deai6a87b07779aaa4d5@mail.gmail.com>
	<BE0FFB47-A15C-48FA-BF1F-32DB24CC5CB1@apple.com>
	<d17b77a40910151232g25d44082vec28aff02ae42bf4@mail.gmail.com>
	<EF9E8F3C-FE54-4C16-95DC-FF5CF4328D9A@apple.com>
	<d17b77a40910151354t1495b11bpe64d3bc745d6eee5@mail.gmail.com>
Message-ID: <5be2d90910151409m21b28d8fj601d0d5f88ca61c3@mail.gmail.com>

Hi,

On Thu, Oct 15, 2009 at 22:54, Juan Carlos Martinez Santos
<juanc.martinez.santos at gmail.com> wrote:
> Hello,
>
> ?I tried to test the qualifier address_space so I used the example in the
> web site: http://clang.llvm.org/docs/LanguageExtensions.html#x86-specific
>
> I used <clang-cc?+ llvm-as + llc>, and I got the expected result; however,
> when I tried to generated the executable, I got the bellow error.
>
> Any idea that what can be wrong.

It looks like you have a source file without a main function. Either
add one, or compile with the -c flag and change addrspace2.exe to
addrspace2.o.

- Anders


From wan at google.com  Thu Oct 15 16:58:32 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Thu, 15 Oct 2009 14:58:32 -0700
Subject: [cfe-dev] last known good revision?
Message-ID: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>

Hi,

I synced llvm and clang to HEAD (r84204) and the build failed (looks
like the header declaring wait(int*) should be #included by
clang/tools/CIndex/CIndex.cpp but isn't).

Since it takes a lot of time to build llvm and clang after each sync,
it would be nice to avoid syncing to a broken revision.  Is there a
place that lists the last known good revision?  Thanks,

-- 
Zhanyong

From dgregor at apple.com  Thu Oct 15 17:06:58 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 15 Oct 2009 15:06:58 -0700
Subject: [cfe-dev] last known good revision?
In-Reply-To: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>
References: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>
Message-ID: <22BA6C8F-7C23-4EB9-A218-1A2A358770FD@apple.com>


On Oct 15, 2009, at 2:58 PM, Zhanyong Wan (?x.x x) wrote:

> Hi,
>
> I synced llvm and clang to HEAD (r84204) and the build failed (looks
> like the header declaring wait(int*) should be #included by
> clang/tools/CIndex/CIndex.cpp but isn't).
>
> Since it takes a lot of time to build llvm and clang after each sync,
> it would be nice to avoid syncing to a broken revision.  Is there a
> place that lists the last known good revision?  Thanks,


We don't keep a list of "known good" revisions.

	- Doug

From john.thompson.jtsoftware at gmail.com  Thu Oct 15 17:09:27 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 15 Oct 2009 15:09:27 -0700
Subject: [cfe-dev] Need Python help in TestRunner.py
In-Reply-To: <6a8523d60910130751t41c3f6c0qbe43dd1eb1390fe1@mail.gmail.com>
References: <aad8390910130719r12729ca7m1519d581d04541ef@mail.gmail.com>
	<6a8523d60910130751t41c3f6c0qbe43dd1eb1390fe1@mail.gmail.com>
Message-ID: <aad8390910151509h2767e3e5k1ab3e01f9256ede7@mail.gmail.com>

Daniel,

Here's a wierd one regarding running the test/Frontend/ast-main.c test on
Windows.  The "diff" utility seems to be crashing when run from the test
scripts in .  Running the same command line from the command shell doesn't
crash:

diff C:\Tools\llvm\tools\clang\test\Frontend\Output\ast-main.c.tmp1.ll
C:\Tools\llvm\tools\clang\test\Frontend\Output\ast-main.c.tmp2.ll

By default, on my system, I'm using the diff from the gnuwin32 utils.  I
also substituted the msys diff, but it crashes also, but only when run under
the test scripts.
Are you seeing this too?

Any thoughts?

-John

On Tue, Oct 13, 2009 at 7:51 AM, Daniel Dunbar <daniel at zuster.org> wrote:

> Hey John,
>
> I'll try to take a look at this soon. File a bug or email me if I seem
> to forget. :)
>
>  - Daniel
>
> On Tue, Oct 13, 2009 at 5:19 PM, John Thompson
> <john.thompson.jtsoftware at gmail.com> wrote:
> > In running the test Driver/ast.c on Windows:
> >
> > 2>  File "C:\Tools\llvm\utils\lit\TestRunner.py", line 79, in
> executeShCmd
> > 2>    raise NotImplementedError,"Unsupported redirect: %r" % (r,)
> > 2>NotImplementedError: Unsupported redirect: (('>>',),
> > 'C:\\Tools\\llvm\\tools\\clang\\test\\Driver\\Output\\ast.c.tmp')
> > It appears that '>>' is not one of the conditions in the if/else series,
> and
> > I don't know Python well enough to fix it.
> >
> > My guess of adding:
> >
> >             elif r[0] == ('>>',):
> >                 redirects[1] = [r[1], 'a', None]
> > resulted in the redirected output being put at the front of the output
> file.
> > So if this is a quick fix for someone, I'd appreciate the help.
> >
> > -John
> > --
> > John Thompson
> > John.Thompson.JTSoftware at gmail.com
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/dfaef7de/attachment.html 

From kremenek at apple.com  Thu Oct 15 17:12:02 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Thu, 15 Oct 2009 15:12:02 -0700
Subject: [cfe-dev] last known good revision?
In-Reply-To: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>
References: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>
Message-ID: <E64C1D27-EFC7-4CEF-93EB-C1060E49B5C4@apple.com>

The best place is to check the status of the Clang buildbots:

http://google1.osuosl.org:8011/console

When the builds are "green" it indicates that the build compiled.

On Oct 15, 2009, at 2:58 PM, Zhanyong Wan (?x.x x) wrote:

> Hi,
>
> I synced llvm and clang to HEAD (r84204) and the build failed (looks
> like the header declaring wait(int*) should be #included by
> clang/tools/CIndex/CIndex.cpp but isn't).
>
> Since it takes a lot of time to build llvm and clang after each sync,
> it would be nice to avoid syncing to a broken revision.  Is there a
> place that lists the last known good revision?  Thanks,
>
> -- 
> Zhanyong
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



From wan at google.com  Thu Oct 15 17:13:27 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Thu, 15 Oct 2009 15:13:27 -0700
Subject: [cfe-dev] last known good revision?
In-Reply-To: <22BA6C8F-7C23-4EB9-A218-1A2A358770FD@apple.com>
References: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>
	<22BA6C8F-7C23-4EB9-A218-1A2A358770FD@apple.com>
Message-ID: <89adf3280910151513l7e977b8fg288f808a2e9ce02b@mail.gmail.com>

I

On Thursday, October 15, 2009, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Oct 15, 2009, at 2:58 PM, Zhanyong Wan (?x.x x) wrote:
>
>
> Hi,
>
> I synced llvm and clang to HEAD (r84204) and the build failed (looks
> like the header declaring wait(int*) should be #included by
> clang/tools/CIndex/CIndex.cpp but isn't).
>
> Since it takes a lot of time to build llvm and clang after each sync,
> it would be nice to avoid syncing to a broken revision. ?Is there a
> place that lists the last known good revision? ?Thanks,
>
>
>
> We don't keep a list of "known good" revisions.
>
>  ? ? ? ?- Doug

Thanks, Doug.  How do people cope with this?  Just keeping fingers crossed? :)

-- 
Zhanyong


From echristo at apple.com  Thu Oct 15 17:19:45 2009
From: echristo at apple.com (Eric Christopher)
Date: Thu, 15 Oct 2009 15:19:45 -0700
Subject: [cfe-dev] last known good revision?
In-Reply-To: <89adf3280910151513l7e977b8fg288f808a2e9ce02b@mail.gmail.com>
References: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>
	<22BA6C8F-7C23-4EB9-A218-1A2A358770FD@apple.com>
	<89adf3280910151513l7e977b8fg288f808a2e9ce02b@mail.gmail.com>
Message-ID: <F3A5A0E2-336D-437D-913D-EE9DFFD384EB@apple.com>


On Oct 15, 2009, at 3:13 PM, Zhanyong Wan (?x.x x) wrote:

> I
>
> On Thursday, October 15, 2009, Douglas Gregor <dgregor at apple.com>  
> wrote:
>>
>> On Oct 15, 2009, at 2:58 PM, Zhanyong Wan (?x.x x) wrote:
>>
>>
>> Hi,
>>
>> I synced llvm and clang to HEAD (r84204) and the build failed (looks
>> like the header declaring wait(int*) should be #included by
>> clang/tools/CIndex/CIndex.cpp but isn't).
>>
>> Since it takes a lot of time to build llvm and clang after each sync,
>> it would be nice to avoid syncing to a broken revision.  Is there a
>> place that lists the last known good revision?  Thanks,
>>
>>
>>
>> We don't keep a list of "known good" revisions.
>>
>>        - Doug
>
> Thanks, Doug.  How do people cope with this?  Just keeping fingers  
> crossed? :)

The buildbots had been mostly green for weeks until I broke them  
yesterday for about an hour. In general the tree isn't broken for very  
long, you can usually just ask or mention it if you get something  
that's broken. The IRC channel is a good place to ask as well.

-eric

From dgregor at apple.com  Thu Oct 15 17:27:14 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 15 Oct 2009 15:27:14 -0700
Subject: [cfe-dev] last known good revision?
In-Reply-To: <89adf3280910151513l7e977b8fg288f808a2e9ce02b@mail.gmail.com>
References: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>
	<22BA6C8F-7C23-4EB9-A218-1A2A358770FD@apple.com>
	<89adf3280910151513l7e977b8fg288f808a2e9ce02b@mail.gmail.com>
Message-ID: <DBB4EA8F-2015-4E2F-854F-00CD4843480C@apple.com>


On Oct 15, 2009, at 3:13 PM, Zhanyong Wan (?x.x x) wrote:

> I
>
> On Thursday, October 15, 2009, Douglas Gregor <dgregor at apple.com>  
> wrote:
>>
>> On Oct 15, 2009, at 2:58 PM, Zhanyong Wan (?x.x x) wrote:
>>
>>
>> Hi,
>>
>> I synced llvm and clang to HEAD (r84204) and the build failed (looks
>> like the header declaring wait(int*) should be #included by
>> clang/tools/CIndex/CIndex.cpp but isn't).
>>
>> Since it takes a lot of time to build llvm and clang after each sync,
>> it would be nice to avoid syncing to a broken revision.  Is there a
>> place that lists the last known good revision?  Thanks,
>>
>>
>>
>> We don't keep a list of "known good" revisions.
>>
>>        - Doug
>
> Thanks, Doug.  How do people cope with this?  Just keeping fingers  
> crossed? :)


The tree doesn't break *that* often, so it hasn't really been a  
problem for me.

	- Doug

From wan at google.com  Thu Oct 15 17:28:11 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Thu, 15 Oct 2009 15:28:11 -0700
Subject: [cfe-dev] last known good revision?
In-Reply-To: <E64C1D27-EFC7-4CEF-93EB-C1060E49B5C4@apple.com>
References: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com> 
	<E64C1D27-EFC7-4CEF-93EB-C1060E49B5C4@apple.com>
Message-ID: <89adf3280910151528r2add277alf0ecebd35545d72d@mail.gmail.com>

2009/10/15 Ted Kremenek <kremenek at apple.com>:
> The best place is to check the status of the Clang buildbots:
>
> http://google1.osuosl.org:8011/console
>
> When the builds are "green" it indicates that the build compiled.

Great!  This is exactly what I need.  Thanks, Ted!

Looks like clang has been broken on Linux since 84199, almost 3 hours
ago.  Is anyone working on a fix?  If not, I'll give it a try.
Thanks,

>
> On Oct 15, 2009, at 2:58 PM, Zhanyong Wan (?x.x x) wrote:
>
>> Hi,
>>
>> I synced llvm and clang to HEAD (r84204) and the build failed (looks
>> like the header declaring wait(int*) should be #included by
>> clang/tools/CIndex/CIndex.cpp but isn't).
>>
>> Since it takes a lot of time to build llvm and clang after each sync,
>> it would be nice to avoid syncing to a broken revision. ?Is there a
>> place that lists the last known good revision? ?Thanks,
>>
>> --
>> Zhanyong
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>



-- 
Zhanyong


From kremenek at apple.com  Thu Oct 15 17:37:14 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Thu, 15 Oct 2009 15:37:14 -0700
Subject: [cfe-dev] last known good revision?
In-Reply-To: <89adf3280910151528r2add277alf0ecebd35545d72d@mail.gmail.com>
References: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com>
	<E64C1D27-EFC7-4CEF-93EB-C1060E49B5C4@apple.com>
	<89adf3280910151528r2add277alf0ecebd35545d72d@mail.gmail.com>
Message-ID: <E73DC526-8546-482A-BBF9-17C24C1DBD77@apple.com>


On Oct 15, 2009, at 3:28 PM, Zhanyong Wan (?x.x x) wrote:

> 2009/10/15 Ted Kremenek <kremenek at apple.com>:
>> The best place is to check the status of the Clang buildbots:
>>
>> http://google1.osuosl.org:8011/console
>>
>> When the builds are "green" it indicates that the build compiled.
>
> Great!  This is exactly what I need.  Thanks, Ted!
>
> Looks like clang has been broken on Linux since 84199, almost 3 hours
> ago.  Is anyone working on a fix?  If not, I'll give it a try.
> Thanks,

Many of the Clang developers aren't developing directly on Linux (we  
just see the failures from the buildbots), so if you have a fix in  
mind by all means please give it a try!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/7ae7afd1/attachment-0001.html 

From john.thompson.jtsoftware at gmail.com  Thu Oct 15 17:40:24 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 15 Oct 2009 15:40:24 -0700
Subject: [cfe-dev] c-index-test?
Message-ID: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>

The Index/c-index-api-test.m test is referencing a c-index-test program, but
the project directory I find for it at clang/tools/c-index-test has a
CMakeLists.txt file that has the MSVC build disabled.

Is this a work in progress?
What should I do?  Just ignore this test for now, or do you need some help
with it?

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/a059b7d8/attachment.html 

From snaroff at apple.com  Thu Oct 15 17:55:42 2009
From: snaroff at apple.com (steve naroff)
Date: Thu, 15 Oct 2009 18:55:42 -0400
Subject: [cfe-dev] c-index-test?
In-Reply-To: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>
References: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>
Message-ID: <659CF62A-FEEC-4F2D-AB33-56A8F7920626@apple.com>


On Oct 15, 2009, at 6:40 PM, John Thompson wrote:

> The Index/c-index-api-test.m test is referencing a c-index-test  
> program, but the project directory I find for it at clang/tools/c- 
> index-test has a CMakeLists.txt file that has the MSVC build disabled.
>
> Is this a work in progress?

Yes.

> What should I do?  Just ignore this test for now, or do you need  
> some help with it?
>

Feel free to enable it for MSVC if you'd like.

snaroff

> -John
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/7db1404d/attachment.html 

From wan at google.com  Thu Oct 15 17:56:24 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Thu, 15 Oct 2009 15:56:24 -0700
Subject: [cfe-dev] last known good revision?
In-Reply-To: <E73DC526-8546-482A-BBF9-17C24C1DBD77@apple.com>
References: <89adf3280910151458g5b53beffk3657bfee190cd6f2@mail.gmail.com> 
	<E64C1D27-EFC7-4CEF-93EB-C1060E49B5C4@apple.com>
	<89adf3280910151528r2add277alf0ecebd35545d72d@mail.gmail.com> 
	<E73DC526-8546-482A-BBF9-17C24C1DBD77@apple.com>
Message-ID: <89adf3280910151556p553dc933mc11c3e1df826f303@mail.gmail.com>

2009/10/15 Ted Kremenek <kremenek at apple.com>:
>
> On Oct 15, 2009, at 3:28 PM, Zhanyong Wan (?x.x x) wrote:
>
> 2009/10/15 Ted Kremenek <kremenek at apple.com>:
>
> The best place is to check the status of the Clang buildbots:
>
> http://google1.osuosl.org:8011/console
>
> When the builds are "green" it indicates that the build compiled.
>
> Great! ?This is exactly what I need. ?Thanks, Ted!
>
> Looks like clang has been broken on Linux since 84199, almost 3 hours
> ago. ?Is anyone working on a fix? ?If not, I'll give it a try.
> Thanks,
>
> Many of the Clang developers aren't developing directly on Linux (we just
> see the failures from the buildbots), so if you have a fix in mind by all
> means please give it a try!

OK.  Just sent my patch to cfe-commits for review.  Thanks!

-- 
Zhanyong


From dgregor at apple.com  Thu Oct 15 18:01:06 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 15 Oct 2009 16:01:06 -0700
Subject: [cfe-dev] c-index-test?
In-Reply-To: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>
References: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>
Message-ID: <A1F7DADA-EA3E-483B-B63D-862BDF217582@apple.com>


On Oct 15, 2009, at 3:40 PM, John Thompson wrote:

> The Index/c-index-api-test.m test is referencing a c-index-test  
> program, but the project directory I find for it at clang/tools/c- 
> index-test has a CMakeLists.txt file that has the MSVC build disabled.
>
> Is this a work in progress?
> What should I do?  Just ignore this test for now, or do you need  
> some help with it?

We could use some help with it. If you enable c-index-test, you'll run  
into the problem described here:

	http://llvm.org/bugs/show_bug.cgi?id=5051

where we are missing dllimport/dllexport markers on the functions in  
libCIndex. There's even a patch there (probably a little bit stale)  
that I can't evaluate because I don't have a Windows machine handy.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/3c7a1467/attachment.html 

From dgregor at apple.com  Thu Oct 15 19:23:32 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 15 Oct 2009 17:23:32 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
Message-ID: <474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>


On Oct 14, 2009, at 8:40 PM, John Thompson wrote:

> Doug,
>
> _Complex is currently a keyword in every mode. We could make it only  
> be a keyword in C99 or GNU mode, then make sure that neither of  
> these modes is turned on by default when Clang is built with VC++.  
> That probably makes sense, since VC++ doesn't support C99 or many  
> GNU extensions anyway.
>
> We can always force tests into specific modes (turning off Microsoft  
> extensions, turning on GNU extensions or C99, whatever), rather than  
> trying to work around problems that are unlikely to show up in code  
> that compiles with VC++.
>
> How would you collectively force the tests?

I don't think we can collectively force the tests; we could explicitly  
add -fno-extensions to the ones that matter.

> I'm kinda feeling that since we're down to just 21 failing tests,  
> and _Complex isn't a problem with VC 9.0, we could probably punt on  
> it for now, and see how it goes with the rest of the tests.  But let  
> me know if you want me to persue this.

Let's punt on it for now, then.

>
> What is the actual issue with the redefinition of wchar_t? Are they  
> creating a typedef of wchar_t in their headers? Does the VC++  
> compiler implicitly define _WCHAR_T_DEFINED?
>
> This occurs in a few headers:
>
> #ifndef _WCHAR_T_DEFINED
> typedef unsigned short wchar_t;
> #define _WCHAR_T_DEFINED
> #endif
>
> The enclosed wchar_t_fix2.patch seems to fix both the wchar_t issue,  
> and another one I ran into with VC++ headers.  I was side-tracked a  
> bit with errors on wchar_t I didn't understand, until I realized  
> that wchar_t was only a C++ keyword.

The wchar_t bits look good. Please go ahead and commit!

> I also ran into some new errors with the VC 9.0 headers on some  
> #pragma's.  Defining _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES avoids  
> them, though it's a bit of a hack.

At the very least, please put a FIXME near that define, since we don't  
want to keep it for long.

>   This symbol prevents the definition of some macros, some of which  
> have errors, for example on __pragma statements like this:
>
> __pragma(warning(push))
>
> This is a Microsoft extension not currently supported, right?  It  
> seems kind of useful for macros.

Right. There are two issues here, I guess. The first is that we don't  
handle __pragma, although it looks like it's similar "enough" to C99's  
_Pragma that it wouldn't be hard to implement this Microsoft  
extension. Second, we have the ability to push/pop diagnostic contexts  
(see the PragmaDiagnosticHandler in lib/Lex/Pragma.cpp) but, IIRC, not  
with that syntax. Again, it's probably simple to implement, or we  
could live with the hack for a bit longer.

> You mentioned that the Targets.cpp was probably not the right place  
> for the defines, so I moved them to InitPreprocessor.cpp.  Is this  
> the right place?

Yep!

> Also, could someone look at the enclosed patch for stdint.h?  This  
> also fixes some failing tests, since VC++ doesn't have stdint.h.   
> Who is point on this?

I'm not thrilled about using _M_IX86 and _M_X64 to detect what is  
really a library issue. I guess in the worst case we could have a  
configure-time check that determines whether we can #include_next  
<stdint.h>, but that's.... horrible.

Unless someone has a better idea... ?

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091015/646ac523/attachment.html 

From wan at google.com  Wed Oct 14 15:59:15 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Wed, 14 Oct 2009 13:59:15 -0700
Subject: [cfe-dev] please review: fix for http://llvm.org/PR4407
In-Reply-To: <89adf3280910141351p593df326h6c6b2b1ca725320@mail.gmail.com>
References: <89adf3280910141348p63b05d03i5224807ec9b24b91@mail.gmail.com> 
	<89adf3280910141351p593df326h6c6b2b1ca725320@mail.gmail.com>
Message-ID: <89adf3280910141359g73d14334p4d925f319f11f51c@mail.gmail.com>

Resending to cfe-commits.  You can tell I'm doing this for the first time. :-)

2009/10/14 Zhanyong Wan (?x.x x) <wan at google.com>:
> 2009/10/14 Zhanyong Wan (?x.x x) <wan at google.com>:
>> Hi,
>>
>> I have a patch that fixes the first issue in http://llvm.org/PR4407 :
>>
>> Clang should warn on a case value that exceeds the range of the type in
>> switch.
>> ?const char ch = 'a';
>> ?switch(ch) {
>> ? ?case 1234: ?// expected-warning {{overflow converting case value}}
>> ? ? ?break;
>> ?}
>>
>> I uploaded the patch to http://codereview.appspot.com/130078/show.
>
> The URL doesn't include the period in the end:
> http://codereview.appspot.com/130078/show
>
> Thanks,
>
>> Could someone review it?
>>
>> This is the first time I work on clang, so please let me know if I'm
>> following the coding convention correctly. ?Thanks,
>>
>> --
>> Zhanyong
>>
>
>
>
> --
> Zhanyong
>



-- 
Zhanyong


From stefanus.du.toit at intel.com  Thu Oct 15 11:34:23 2009
From: stefanus.du.toit at intel.com (Du Toit, Stefanus)
Date: Thu, 15 Oct 2009 10:34:23 -0600
Subject: [cfe-dev] [LLVMdev]  Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <2C2ECF4B05BCF3489866AB805260FEC504CE39F3A0@rrsmsx509.amr.corp.intel.com>

Hi Chris,

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Chris Lattner
> Sent: Thursday, October 15, 2009 11:45 AM
> To: Anton Korobeynikov
> Cc: clang-dev Developers; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] [cfe-dev] Developer meeting videos up
> 
> Unfortunately, we found out at the last minute that Apple has a rule
> which prevents its engineers from giving video taped talks or
> distributing slides.  We will hold onto the video and slide assets in
> case this rule changes in the future.

That's really too bad. Due to a meeting conflict I was unable to attend Dan's talk on ScalarEvolution, but it was one of the ones I was most interested in seeing given our interest in loop optimization. I also missed the beginning of Lang's talk on future register allocation work, which we also have a keen interest in. I expect a lot of people would be very interested in Nate's OpenCL talk as well, given the current interest in OpenCL and that it's a nice real-world example of LLVM usage.

It would be great if an exception could be made for these somehow. I know there are others interested in seeing them as well who were unable to attend the meeting in person.

Thanks,

Stefanus

--
Stefanus Du Toit <stefanus.du.toit at intel.com>
  Intel PPL/DPD/SSG
  phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463



From daniel at zuster.org  Thu Oct 15 20:09:48 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 15 Oct 2009 18:09:48 -0700
Subject: [cfe-dev] Command Line Bugzilla
Message-ID: <6a8523d60910151809h75664a3eh876472a624266a23@mail.gmail.com>

Hi all,

Thought this might be of general interest, I hacked up the pybugz tool
to work with llvm.org. It's here if you want it:
  http://t1.minormatter.com/~ddunbar/pybugz-llvm-0.7.3.tgz

Unpack somewhere, and make a link to the 'bugz' script. Usage:
--
ddunbar at ozzy-2:~$ bugz get 1000
 * Using http://llvm.org/bugs/
 * Getting bug 1000 ..
Title       : Chris Is Buggy
Assignee    : tonic at nondot.org
...

ddunbar at ozzy-2:~$ bugz search foo
 * Using http://llvm.org/bugs/
 * Searching for 'foo'
   3053 unassignedclangbugs  clang doesn't check foo(int a[static 10]) callers
   3984 unassignedclangbugs  [driver] clang foo.c -std=c++98 doesn't treat inpu
   4120 unassignedclangbugs  better error recovery for digraph confusion: <::fo
   4519 kremenek             [[[[Foo alloc] init] bar] release] marked as Bad r
   4941 unassignedclangbugs  clang-cc should support -fno-builtin-foo
--

Various parameters are probably hard coded to my usage, use at your
own risk. I usually don't create bugs with it, just search and fetch.

I find its much nicer for searching bugzilla, in particular.

 - Daniel

From xuzhongxing at gmail.com  Fri Oct 16 01:42:51 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Fri, 16 Oct 2009 14:42:51 +0800
Subject: [cfe-dev] Command Line Bugzilla
In-Reply-To: <6a8523d60910151809h75664a3eh876472a624266a23@mail.gmail.com>
References: <6a8523d60910151809h75664a3eh876472a624266a23@mail.gmail.com>
Message-ID: <5400aeb80910152342x4c87f500r47f6ffbaafcdbf87@mail.gmail.com>

Hi Daniel,

Thanks. I'm using it. It's handy.

2009/10/16 Daniel Dunbar <daniel at zuster.org>:
> Hi all,
>
> Thought this might be of general interest, I hacked up the pybugz tool
> to work with llvm.org. It's here if you want it:
> ?http://t1.minormatter.com/~ddunbar/pybugz-llvm-0.7.3.tgz
>
> Unpack somewhere, and make a link to the 'bugz' script. Usage:
> --
> ddunbar at ozzy-2:~$ bugz get 1000
> ?* Using http://llvm.org/bugs/
> ?* Getting bug 1000 ..
> Title ? ? ? : Chris Is Buggy
> Assignee ? ?: tonic at nondot.org
> ...
>
> ddunbar at ozzy-2:~$ bugz search foo
> ?* Using http://llvm.org/bugs/
> ?* Searching for 'foo'
> ? 3053 unassignedclangbugs ?clang doesn't check foo(int a[static 10]) callers
> ? 3984 unassignedclangbugs ?[driver] clang foo.c -std=c++98 doesn't treat inpu
> ? 4120 unassignedclangbugs ?better error recovery for digraph confusion: <::fo
> ? 4519 kremenek ? ? ? ? ? ? [[[[Foo alloc] init] bar] release] marked as Bad r
> ? 4941 unassignedclangbugs ?clang-cc should support -fno-builtin-foo
> --
>
> Various parameters are probably hard coded to my usage, use at your
> own risk. I usually don't create bugs with it, just search and fetch.
>
> I find its much nicer for searching bugzilla, in particular.
>
> ?- Daniel
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From Fons.Rademakers at cern.ch  Fri Oct 16 02:52:02 2009
From: Fons.Rademakers at cern.ch (Fons Rademakers)
Date: Fri, 16 Oct 2009 09:52:02 +0200
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <4AD82622.8090301@cern.ch>

Hi Chris,

   it would be good if "the powers that be" could be made to understand 
that if only Apple employees are not allowed to put up their slides while 
Apple is employing the core of the LLVM foundation, that this sends the 
absolute wrong message on openness of the project. It is also totally 
incompatible with the fantastic work you guys are doing and your tremendous 
presence on the (non Apple) uiuc mailings lists.

At CERN we had already a number of people questioning the wisdom of basing 
our developments on LLVM as it is perceived as an Apple thing, that could 
turn on us at anytime, and this position does not help.

Cheers, Fons.


Chris Lattner wrote:
> On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote:
>> Hi, Chris
>>
>>> All of the videos are now up on the web page, and most of the slides
>>> are up (still need to get David's and Evan's slides).  Please let me
>>> know if you hit any problems.
>> First of all, thanks a lot about all stuff with videos & slides  
>> posting.
>>
>> I'm a bit curious: is there any reason why are other slides / videos
>> not available (it seems that the ones missing are from Apple folks)?
> 
> Unfortunately, we found out at the last minute that Apple has a rule  
> which prevents its engineers from giving video taped talks or  
> distributing slides.  We will hold onto the video and slide assets in  
> case this rule changes in the future.
> 
> -Chris
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640

From Axel.Naumann at cern.ch  Fri Oct 16 03:11:25 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Fri, 16 Oct 2009 10:11:25 +0200
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <4AD82AAD.9060408@cern.ch>

Hi Chris,

Chris Lattner wrote on 10/15/2009 05:45 PM:
> On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote:
>>
>> I'm a bit curious: is there any reason why are other slides / videos
>> not available (it seems that the ones missing are from Apple folks)?
> 
> Unfortunately, we found out at the last minute that Apple has a rule  
> which prevents its engineers from giving video taped talks or  
> distributing slides.  We will hold onto the video and slide assets in  
> case this rule changes in the future.

can you maybe ask a public relations colleague to post at least the
slides? Even if it takes a while: not having them at all is very bad
publicity for Apple. It proves (esp to people like GCC, but also
colleagues here at CERN) that Apple is the wrong place to host an open
source project, and that Apple is doing its best at diverting efforts
into its proprietary domain.

Don't get me wrong: I really appreciate Apple's efforts in hosting the
workshop and paying 90% of the developers of LLVM!

Cheers, Axel.


From john.thompson.jtsoftware at gmail.com  Fri Oct 16 12:39:07 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Fri, 16 Oct 2009 10:39:07 -0700
Subject: [cfe-dev] c-index-test?
In-Reply-To: <aad8390910161038q2568eb00o1411a5a804e59095@mail.gmail.com>
References: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>
	<A1F7DADA-EA3E-483B-B63D-862BDF217582@apple.com>
	<aad8390910161038q2568eb00o1411a5a804e59095@mail.gmail.com>
Message-ID: <aad8390910161039h3b55d0dbx5872483ac80b2a41@mail.gmail.com>

 Question:  Why does this library need to be a shared library?  It seems all
the other libraries are not.

The missing basename symbol is a problem.  I took a guess that it returns a
pointer to the base part of a file path (i.e. given "/path/basename.ext", it
will return a pointer to the "basename.ext" part), but the test still
fails.  I'll look into it more later today.

What is this app for?

-John
  On Thu, Oct 15, 2009 at 4:01 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
>  On Oct 15, 2009, at 3:40 PM, John Thompson wrote:
>
>  The Index/c-index-api-test.m test is referencing a c-index-test program,
> but the project directory I find for it at clang/tools/c-index-test has a
> CMakeLists.txt file that has the MSVC build disabled.
>
> Is this a work in progress?
> What should I do?  Just ignore this test for now, or do you need some help
> with it?
>
>
> We could use some help with it. If you enable c-index-test, you'll run into
> the problem described here:
>
> http://llvm.org/bugs/show_bug.cgi?id=5051
>
> where we are missing dllimport/dllexport markers on the functions in
> libCIndex. There's even a patch there (probably a little bit stale) that I
> can't evaluate because I don't have a Windows machine handy.
>
> - Doug
>



 --
John Thompson
John.Thompson.JTSoftware at gmail.com




-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091016/b969ced3/attachment.html 

From dag at cray.com  Fri Oct 16 12:36:35 2009
From: dag at cray.com (David Greene)
Date: Fri, 16 Oct 2009 12:36:35 -0500
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <4AD82622.8090301@cern.ch>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<4AD82622.8090301@cern.ch>
Message-ID: <200910161236.35627.dag@cray.com>

On Friday 16 October 2009 02:52, Fons Rademakers wrote:

> At CERN we had already a number of people questioning the wisdom of basing
> our developments on LLVM as it is perceived as an Apple thing, that could
> turn on us at anytime, and this position does not help.

Ditto.  I've heard this more than once from people here.

                              -Dave

From kremenek at apple.com  Fri Oct 16 12:54:39 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Fri, 16 Oct 2009 10:54:39 -0700
Subject: [cfe-dev] c-index-test?
In-Reply-To: <aad8390910161039h3b55d0dbx5872483ac80b2a41@mail.gmail.com>
References: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>
	<A1F7DADA-EA3E-483B-B63D-862BDF217582@apple.com>
	<aad8390910161038q2568eb00o1411a5a804e59095@mail.gmail.com>
	<aad8390910161039h3b55d0dbx5872483ac80b2a41@mail.gmail.com>
Message-ID: <9B08EFDC-7364-4D9E-A4F0-11629D4F31F3@apple.com>

On Oct 16, 2009, at 10:39 AM, John Thompson wrote:

> Question:  Why does this library need to be a shared library?  It  
> seems all the other libraries are not.

Yes.  This library differs from the other libraries in that it vends a  
stable C API instead of an internal C++ API.  This shared library is  
intended be used as a component of other software that wishes to use  
Clang through a stable interface but not be directly exposed to  
Clang's internal implementation.

We already have a precedent for a shared library in LLVM: lto.  I'm  
not certain if that builds on Windows or not.  If it doesn't, we can  
always disable building the CIndex shared library on Windows until  
someone cares to support it on that platform.

>
> The missing basename symbol is a problem.  I took a guess that it  
> returns a pointer to the base part of a file path (i.e. given "/path/ 
> basename.ext", it will return a pointer to the "basename.ext" part),  
> but the test still fails.  I'll look into it more later today.

Thanks!

> What is this app for?

The shared library is meant to service a general purpose, relatively  
stable C API (in evolution) for building applications on top of Clang  
that want to perform some kind of reasoning about source code without  
directly interacting with Clang's internals.

From espindola at google.com  Fri Oct 16 14:00:24 2009
From: espindola at google.com (Rafael Espindola)
Date: Fri, 16 Oct 2009 15:00:24 -0400
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <4AD82AAD.9060408@cern.ch>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<4AD82AAD.9060408@cern.ch>
Message-ID: <38a0d8450910161200i40d737d7r5bfd86dd6c8f7044@mail.gmail.com>

> can you maybe ask a public relations colleague to post at least the
> slides? Even if it takes a while: not having them at all is very bad
> publicity for Apple. It proves (esp to people like GCC, but also
> colleagues here at CERN) that Apple is the wrong place to host an open
> source project, and that Apple is doing its best at diverting efforts
> into its proprietary domain.

I was told that before when setting up a previous project:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-April/005663.html

Once one is actually involved in the llvm development, it is very
nice. Just avoiding bad PR would probably get more people in.

>
> Cheers, Axel.

Cheers,
-- 
Rafael ?vila de Esp?ndola


From juanc.martinez.santos at gmail.com  Fri Oct 16 16:30:30 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Fri, 16 Oct 2009 17:30:30 -0400
Subject: [cfe-dev] [LLVMdev] named address spaces
In-Reply-To: <0727CC2A-B8A7-4975-83B3-B368E27F568B@apple.com>
References: <d17b77a40910161322g2b0053adj1ca4ce39fd0dcc37@mail.gmail.com>
	<0727CC2A-B8A7-4975-83B3-B368E27F568B@apple.com>
Message-ID: <d17b77a40910161430k60178f1k4b8dab4a5b74c463@mail.gmail.com>

Hello,

If I want implement other address spaces (for x86), can I modify my back-end
(clang) to support other address spaces (at least two data segments, two
heaps, and two stacks?

How will be the mechanism? For example, for256/257, I see two reference
points (FS and GP). Would I need to specify a different reference to
each memory region? Where is the best site to add the modifications?

Thanks in advance,

Juan Carlos

On Fri, Oct 16, 2009 at 4:34 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Oct 16, 2009, at 1:22 PM, Juan Carlos Martinez Santos wrote:
>
> Hello,
>>
>> If my understand is correct, LLVM supports the address_space qualifier;
>> however, how I can add custom address spaces. Where I can declare them? For
>> clang (x86), I saw that address spaces #256 and #257 works well (I see the
>> generated code with the 'gs' and 'fs'), but when I select different ones, I
>> don't see any different.
>>
>>
> Address spaces are target specific.  The 256/257 address spaces on x86 are
> implemented in the X86 backend, for example.
>
> -Chris
>
>


-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091016/6e0fc993/attachment.html 

From luoyonggang at gmail.com  Fri Oct 16 19:25:36 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sat, 17 Oct 2009 08:25:36 +0800
Subject: [cfe-dev] c-index-test?
In-Reply-To: <9B08EFDC-7364-4D9E-A4F0-11629D4F31F3@apple.com>
References: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>
	<A1F7DADA-EA3E-483B-B63D-862BDF217582@apple.com>
	<aad8390910161038q2568eb00o1411a5a804e59095@mail.gmail.com>
	<aad8390910161039h3b55d0dbx5872483ac80b2a41@mail.gmail.com>
	<9B08EFDC-7364-4D9E-A4F0-11629D4F31F3@apple.com>
Message-ID: <806065d90910161725l3e983081q80605d3b4089d09a@mail.gmail.com>

Yes, it's can be build!

2009/10/17, Ted Kremenek <kremenek at apple.com>:
> On Oct 16, 2009, at 10:39 AM, John Thompson wrote:
>
>> Question:  Why does this library need to be a shared library?  It
>> seems all the other libraries are not.
>
> Yes.  This library differs from the other libraries in that it vends a
> stable C API instead of an internal C++ API.  This shared library is
> intended be used as a component of other software that wishes to use
> Clang through a stable interface but not be directly exposed to
> Clang's internal implementation.
>
> We already have a precedent for a shared library in LLVM: lto.  I'm
> not certain if that builds on Windows or not.  If it doesn't, we can
> always disable building the CIndex shared library on Windows until
> someone cares to support it on that platform.
>
>>
>> The missing basename symbol is a problem.  I took a guess that it
>> returns a pointer to the base part of a file path (i.e. given "/path/
>> basename.ext", it will return a pointer to the "basename.ext" part),
>> but the test still fails.  I'll look into it more later today.
>
> Thanks!
>
>> What is this app for?
>
> The shared library is meant to service a general purpose, relatively
> stable C API (in evolution) for building applications on top of Clang
> that want to perform some kind of reasoning about source code without
> directly interacting with Clang's internals.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From kremenek at apple.com  Fri Oct 16 19:30:56 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Fri, 16 Oct 2009 17:30:56 -0700
Subject: [cfe-dev] c-index-test?
In-Reply-To: <806065d90910161725l3e983081q80605d3b4089d09a@mail.gmail.com>
References: <aad8390910151540o6897578fk57c1f52fede05859@mail.gmail.com>
	<A1F7DADA-EA3E-483B-B63D-862BDF217582@apple.com>
	<aad8390910161038q2568eb00o1411a5a804e59095@mail.gmail.com>
	<aad8390910161039h3b55d0dbx5872483ac80b2a41@mail.gmail.com>
	<9B08EFDC-7364-4D9E-A4F0-11629D4F31F3@apple.com>
	<806065d90910161725l3e983081q80605d3b4089d09a@mail.gmail.com>
Message-ID: <5443CFAC-B0AB-4DF0-8696-D1B3EAA2CD49@apple.com>

Wonderful!  Great to know!

On Oct 16, 2009, at 5:25 PM, ???(Yonggang Luo) wrote:

> Yes, it's can be build!
>
> 2009/10/17, Ted Kremenek <kremenek at apple.com>:
>> On Oct 16, 2009, at 10:39 AM, John Thompson wrote:
>>
>>> Question:  Why does this library need to be a shared library?  It
>>> seems all the other libraries are not.
>>
>> Yes.  This library differs from the other libraries in that it  
>> vends a
>> stable C API instead of an internal C++ API.  This shared library is
>> intended be used as a component of other software that wishes to use
>> Clang through a stable interface but not be directly exposed to
>> Clang's internal implementation.
>>
>> We already have a precedent for a shared library in LLVM: lto.  I'm
>> not certain if that builds on Windows or not.  If it doesn't, we can
>> always disable building the CIndex shared library on Windows until
>> someone cares to support it on that platform.
>>
>>>
>>> The missing basename symbol is a problem.  I took a guess that it
>>> returns a pointer to the base part of a file path (i.e. given "/ 
>>> path/
>>> basename.ext", it will return a pointer to the "basename.ext" part),
>>> but the test still fails.  I'll look into it more later today.
>>
>> Thanks!
>>
>>> What is this app for?
>>
>> The shared library is meant to service a general purpose, relatively
>> stable C API (in evolution) for building applications on top of Clang
>> that want to perform some kind of reasoning about source code without
>> directly interacting with Clang's internals.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
> -- 
> ?????????
>
>         ??
> ?
> ???
> Yours
>    sincerely,
> Yonggang Luo



From luoyonggang at gmail.com  Fri Oct 16 20:31:43 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sat, 17 Oct 2009 09:31:43 +0800
Subject: [cfe-dev] Mingw compiling error
Message-ID: <806065d90910161831u41f13f1ai6f322c3abbe54f24@mail.gmail.com>

[ 93%] Building CXX object
tools/clang/lib/Frontend/CMakeFiles/clangFrontend.dir/ASTConsumers.cpp.obj
cd D:\objs\llvm\eclipse\tools\clang\lib\Frontend &&
D:\Tools\Building\gcc\bin\g++.exe   -D_DEBUG -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -fno-common -Woverloaded-virtual
-pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings
-ID:\objs\llvm\eclipse\include -IE:\Downloads\llvm-trunk\include
-IE:\Downloads\llvm-trunk\tools\clang\include
-ID:\objs\llvm\eclipse\tools\clang\include   -o
CMakeFiles\clangFrontend.dir\ASTConsumers.cpp.obj -c
E:\Downloads\llvm-trunk\tools\clang\lib\Frontend\ASTConsumers.cpp
D:\Tools\Building\cmake\bin\cmake.exe -E cmake_progress_report
D:\objs\llvm\eclipse\CMakeFiles 86
[ 94%] Building CXX object
tools/clang/lib/Frontend/CMakeFiles/clangFrontend.dir/ASTUnit.cpp.obj
cd D:\objs\llvm\eclipse\tools\clang\lib\Frontend &&
D:\Tools\Building\gcc\bin\g++.exe   -D_DEBUG -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -fno-common -Woverloaded-virtual
-pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings
-ID:\objs\llvm\eclipse\include -IE:\Downloads\llvm-trunk\include
-IE:\Downloads\llvm-trunk\tools\clang\include
-ID:\objs\llvm\eclipse\tools\clang\include   -o
CMakeFiles\clangFrontend.dir\ASTUnit.cpp.obj -c
E:\Downloads\llvm-trunk\tools\clang\lib\Frontend\ASTUnit.cpp
E:\Downloads\llvm-trunk\tools\clang\lib\Frontend\ASTUnit.cpp: In destructor
'clang::ASTUnit::~ASTUnit()':
E:\Downloads\llvm-trunk\tools\clang\lib\Frontend\ASTUnit.cpp:30: error:
'unlink' was not declared in this scope
mingw32-make[2]: ***
[tools/clang/lib/Frontend/CMakeFiles/clangFrontend.dir/ASTUnit.cpp.obj]
Error 1
mingw32-make[2]: Leaving directory `D:/objs/llvm/eclipse'
mingw32-make[1]: ***
[tools/clang/lib/Frontend/CMakeFiles/clangFrontend.dir/all] Error 2
mingw32-make[1]: Leaving directory `D:/objs/llvm/eclipse'

-- 
        ??
?
???
Yours
   sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091017/9667a2ad/attachment.html 

From daniel at zuster.org  Fri Oct 16 20:41:34 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 16 Oct 2009 18:41:34 -0700
Subject: [cfe-dev] Target.cpp
In-Reply-To: <aad8390909241855k5409a6casc27b1c77991179cc@mail.gmail.com>
References: <aad8390909222321h15032d0ei49ad043edd2927@mail.gmail.com>
	<6a8523d60909230034x48207694lc751cf074dfcc6d9@mail.gmail.com>
	<aad8390909231310u53f25dads83ef045b2f859a02@mail.gmail.com>
	<6a8523d60909240004u12e6099ft93a1f6dd5784ae0c@mail.gmail.com>
	<aad8390909241855k5409a6casc27b1c77991179cc@mail.gmail.com>
Message-ID: <6a8523d60910161841o36437777p66578fc747a86dcd@mail.gmail.com>

On Thu, Sep 24, 2009 at 6:55 PM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> Daniel,
>
>> Unless someone objects, I think the MSVC parts are worth putting it.
> I'm not sure about the Cygwin/MinGW changes, were these intentional?
> Oh, I see there are problems there, as?I deleted?the?lines?picking up the
> C++ headers.? This is problematic, with the include paths having compiler
> version numbers.
>
> I'm actually at gcc 4.4.0 in MinGW (which doesn't work for me, if you saw
> the email I just posted).? Should I install 4.3.0 and put back the deleted
> paths?? Or should we move to 4.4.0 and change the paths accordingly?? I'll
> wait to hear before I do anything.

For now I think its ok to have both.

 - Daniel

> -John
> On Thu, Sep 24, 2009 at 12:04 AM, Daniel Dunbar <daniel at zuster.org> wrote:
>>
>> On Wed, Sep 23, 2009 at 1:10 PM, John Thompson
>> <john.thompson.jtsoftware at gmail.com> wrote:
>> > Hi Daniel,
>> >
>> > Thanks.
>> >
>> >> By the way, I still don't have all my local patches in for testing on
>> > Windows (there are basically 3, one to add count + not to
>> > test/Scripts, one to add my local search headers, and one to hack
>> > around stdint.h), but the current number of test failures is ~60,
>> > which isn't too bad. A lot of the remaining ones are STL iterator
>> > pickyness which should be easy to eliminate if someone sits down to
>> > work through them.
>>
>> > I still have the local patches you gave me before, which I was using,
>> > somewhat successfully, though the three of use trying the tests saw some
>> > different results.??But that was a couple months ago, with me being
>> > pulled
>> > onto other projects and vacation, so I'll see about running them again,
>> > if I
>> > can figure out how I was running them before.
>>
>> The way I am running them now is using the "clang-test" project in the
>> project files. That should be the "official" way for MSVC (from a
>> CMake build), and ideally will "just work" one day.
>>
>> In fact, this is now working in buildbot too!
>> ?http://google1.osuosl.org:8011/waterfall
>> The buildbot of course has a higher test failure count because it
>> doesn't get my local patches. The current count is 73 after the fixes
>> for count/not which just went in.
>>
>> >? I'll start looking at those test failures, hoping it's not too far over
>> > my head.
>>
>> I suspect a number of the issues are trivial things regarding to the
>> use of the debug STL library, which is much pickier on Windows. For
>> example, all the static analyzer tests were failing due to code like
>> '&*t.end()'. Then there is a group of tests that use /dev/null, I will
>> probably fix this in 'lit'. Finally there are issues with standard
>> include files not being usable. Those are the three major classes of
>> failures I am aware of.
>>
>> >? I do look forward to
>> > having the full solution for running the tests.
>>
>> >> Also, what happened with your patch to add MSVC search paths in a more
>> > principled fashion? In my fuzzy memory I thought it had gone in, but I
>> > didn't actually see it in the source.
>> > Regarding the include path patch, it was kind of a hack job, mainly to
>> > facilitate our development.? I think you or someone raised some
>> > objection
>> > about one part where when both vc80 and c90 are present (both the
>> > VS80COMNTOOLS and VS90COMNTOOLS environment variables are set) and I
>> > used
>> > the one Clang was built with.? I kind of left it at that.
>> >
>> > How do you think I should handle this case?? Just use whichever is the
>> > later
>> > VS release?
>>
>> For now, anything is better than nothing. Using the version the tools
>> was built with would be a fine start I guess, and perhaps closer to
>> what the user would want.
>>
>> > I've enclosed a refreshed patch, in case you want to see it again.? It
>> > still
>> > has some hard-coded paths like before, which is also why it's kind of
>> > hackish.
>>
>> Unless someone objects, I think the MSVC parts are worth putting it.
>> I'm not sure about the Cygwin/MinGW changes, were these intentional?
>>
>> ?- Daniel
>>
>> > On Wed, Sep 23, 2009 at 12:34 AM, Daniel Dunbar <daniel at zuster.org>
>> > wrote:
>> >>
>> >> Hi John,
>> >>
>> >> Thanks for the refactoring, it looks good to me, I applied as r82621.
>> >>
>> >> On Tue, Sep 22, 2009 at 11:21 PM, John Thompson
>> >> <john.thompson.jtsoftware at gmail.com> wrote:
>> >> > Hi Daniel,
>> >> > Sorry for the duplicate email, I keep forgetting to pay attention to
>> >> > the
>> >> > return address.
>> >> > I've redone?the patch?without the Triple changes.? The current triple
>> >> > mechanism seems a bit out-of-date, as the correct triple for 64-bit
>> >> > Windows
>> >> > appears to be "x86_64-pc-win32", but we can leave that for whoever
>> >> > owns
>> >> > it.
>> >>
>> >> Ok.
>> >>
>> >> > At some point, if Clang wants to be it's own environment on Windows,
>> >> > we'll
>> >> > probably have to revise this a bit to be able to do something other
>> >> > than
>> >> > default to Visual Studio for the "win32" OS-type, but this is
>> >> > probably
>> >> > good
>> >> > enough for now.
>> >>
>> >> Yeah, we will probably want to go a long time before we care about
>> >> this. Adoption means being compatible with the existing environment,
>> >> as painful as it may be.
>> >>
>> >> > Thanks for dealing with this for me.
>> >> >
>> >> > -John
>> >> >
>> >> > P.S.? I added an empty define for __declspec.? Is this all that's
>> >> > needed?
>> >>
>> >> Dunno...
>> >>
>> >> By the way, I still don't have all my local patches in for testing on
>> >> Windows (there are basically 3, one to add count + not to
>> >> test/Scripts, one to add my local search headers, and one to hack
>> >> around stdint.h), but the current number of test failures is ~60,
>> >> which isn't too bad. A lot of the remaining ones are STL iterator
>> >> pickyness which should be easy to eliminate if someone sits down to
>> >> work through them.
>> >>
>> >> Also, what happened with your patch to add MSVC search paths in a more
>> >> principled fashion? In my fuzzy memory I thought it had gone in, but I
>> >> didn't actually see it in the source.
>> >>
>> >> ?- Daniel
>> >
>> >
>> >
>> > --
>> > John Thompson
>> > John.Thompson.JTSoftware at gmail.com
>> >
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >
>> >
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


From daniel at zuster.org  Fri Oct 16 20:42:22 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 16 Oct 2009 18:42:22 -0700
Subject: [cfe-dev] Target.cpp
In-Reply-To: <aad8390909251805h3912f217ke673067b6c6d3ecb@mail.gmail.com>
References: <aad8390909222321h15032d0ei49ad043edd2927@mail.gmail.com>
	<6a8523d60909230034x48207694lc751cf074dfcc6d9@mail.gmail.com>
	<aad8390909231310u53f25dads83ef045b2f859a02@mail.gmail.com>
	<6a8523d60909240004u12e6099ft93a1f6dd5784ae0c@mail.gmail.com>
	<aad8390909241855k5409a6casc27b1c77991179cc@mail.gmail.com>
	<aad8390909251805h3912f217ke673067b6c6d3ecb@mail.gmail.com>
Message-ID: <6a8523d60910161842g32776674iee7a9e279a4d7f7f@mail.gmail.com>

On Fri, Sep 25, 2009 at 6:05 PM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> Here's a revised patch for the Windows include paths, putting back the
> deleted lines for MinGW and Cygwin?with a little revision.? Note that I
> can't test the MinGW and Cygwin stuff, because I can't?get those SKUs to
> build.
>
> Also, another issue I brought up before but only remembered recently was
> that the old Python test runner wasn't passing through the environment, so
> the Visual Studio environment variables (and C_INCLUDE_PATH) can't be seen.
> I think you need to explicitly pass them through, but I wasn't sure how to
> do it.? Is this still an issue with the new script?

This is easy to change, just let me know which environment variables
to propagate.

 - Daniel

> -John
> On Thu, Sep 24, 2009 at 6:55 PM, John Thompson
> <john.thompson.jtsoftware at gmail.com> wrote:
>>
>> Daniel,
>>
>> > Unless someone objects, I think the MSVC parts are worth putting it.
>> I'm not sure about the Cygwin/MinGW changes, were these intentional?
>> Oh, I see there are problems there, as?I deleted?the?lines?picking up the
>> C++ headers.? This is problematic, with the include paths having compiler
>> version numbers.
>>
>> I'm actually at gcc 4.4.0 in MinGW (which doesn't work for me, if you saw
>> the email I just posted).? Should I install 4.3.0 and put back the deleted
>> paths?? Or should we move to 4.4.0 and change the paths accordingly?? I'll
>> wait to hear before I do anything.
>>
>> -John
>> On Thu, Sep 24, 2009 at 12:04 AM, Daniel Dunbar <daniel at zuster.org> wrote:
>>>
>>> On Wed, Sep 23, 2009 at 1:10 PM, John Thompson
>>> <john.thompson.jtsoftware at gmail.com> wrote:
>>> > Hi Daniel,
>>> >
>>> > Thanks.
>>> >
>>> >> By the way, I still don't have all my local patches in for testing on
>>> > Windows (there are basically 3, one to add count + not to
>>> > test/Scripts, one to add my local search headers, and one to hack
>>> > around stdint.h), but the current number of test failures is ~60,
>>> > which isn't too bad. A lot of the remaining ones are STL iterator
>>> > pickyness which should be easy to eliminate if someone sits down to
>>> > work through them.
>>>
>>> > I still have the local patches you gave me before, which I was using,
>>> > somewhat successfully, though the three of use trying the tests saw
>>> > some
>>> > different results.??But that was a couple months ago, with me being
>>> > pulled
>>> > onto other projects and vacation, so I'll see about running them again,
>>> > if I
>>> > can figure out how I was running them before.
>>>
>>> The way I am running them now is using the "clang-test" project in the
>>> project files. That should be the "official" way for MSVC (from a
>>> CMake build), and ideally will "just work" one day.
>>>
>>> In fact, this is now working in buildbot too!
>>> ?http://google1.osuosl.org:8011/waterfall
>>> The buildbot of course has a higher test failure count because it
>>> doesn't get my local patches. The current count is 73 after the fixes
>>> for count/not which just went in.
>>>
>>> >? I'll start looking at those test failures, hoping it's not too far
>>> > over my head.
>>>
>>> I suspect a number of the issues are trivial things regarding to the
>>> use of the debug STL library, which is much pickier on Windows. For
>>> example, all the static analyzer tests were failing due to code like
>>> '&*t.end()'. Then there is a group of tests that use /dev/null, I will
>>> probably fix this in 'lit'. Finally there are issues with standard
>>> include files not being usable. Those are the three major classes of
>>> failures I am aware of.
>>>
>>> >? I do look forward to
>>> > having the full solution for running the tests.
>>>
>>> >> Also, what happened with your patch to add MSVC search paths in a more
>>> > principled fashion? In my fuzzy memory I thought it had gone in, but I
>>> > didn't actually see it in the source.
>>> > Regarding the include path patch, it was kind of a hack job, mainly to
>>> > facilitate our development.? I think you or someone raised some
>>> > objection
>>> > about one part where when both vc80 and c90 are present (both the
>>> > VS80COMNTOOLS and VS90COMNTOOLS environment variables are set) and I
>>> > used
>>> > the one Clang was built with.? I kind of left it at that.
>>> >
>>> > How do you think I should handle this case?? Just use whichever is the
>>> > later
>>> > VS release?
>>>
>>> For now, anything is better than nothing. Using the version the tools
>>> was built with would be a fine start I guess, and perhaps closer to
>>> what the user would want.
>>>
>>> > I've enclosed a refreshed patch, in case you want to see it again.? It
>>> > still
>>> > has some hard-coded paths like before, which is also why it's kind of
>>> > hackish.
>>>
>>> Unless someone objects, I think the MSVC parts are worth putting it.
>>> I'm not sure about the Cygwin/MinGW changes, were these intentional?
>>>
>>> ?- Daniel
>>>
>>> > On Wed, Sep 23, 2009 at 12:34 AM, Daniel Dunbar <daniel at zuster.org>
>>> > wrote:
>>> >>
>>> >> Hi John,
>>> >>
>>> >> Thanks for the refactoring, it looks good to me, I applied as r82621.
>>> >>
>>> >> On Tue, Sep 22, 2009 at 11:21 PM, John Thompson
>>> >> <john.thompson.jtsoftware at gmail.com> wrote:
>>> >> > Hi Daniel,
>>> >> > Sorry for the duplicate email, I keep forgetting to pay attention to
>>> >> > the
>>> >> > return address.
>>> >> > I've redone?the patch?without the Triple changes.? The current
>>> >> > triple
>>> >> > mechanism seems a bit out-of-date, as the correct triple for 64-bit
>>> >> > Windows
>>> >> > appears to be "x86_64-pc-win32", but we can leave that for whoever
>>> >> > owns
>>> >> > it.
>>> >>
>>> >> Ok.
>>> >>
>>> >> > At some point, if Clang wants to be it's own environment on Windows,
>>> >> > we'll
>>> >> > probably have to revise this a bit to be able to do something other
>>> >> > than
>>> >> > default to Visual Studio for the "win32" OS-type, but this is
>>> >> > probably
>>> >> > good
>>> >> > enough for now.
>>> >>
>>> >> Yeah, we will probably want to go a long time before we care about
>>> >> this. Adoption means being compatible with the existing environment,
>>> >> as painful as it may be.
>>> >>
>>> >> > Thanks for dealing with this for me.
>>> >> >
>>> >> > -John
>>> >> >
>>> >> > P.S.? I added an empty define for __declspec.? Is this all that's
>>> >> > needed?
>>> >>
>>> >> Dunno...
>>> >>
>>> >> By the way, I still don't have all my local patches in for testing on
>>> >> Windows (there are basically 3, one to add count + not to
>>> >> test/Scripts, one to add my local search headers, and one to hack
>>> >> around stdint.h), but the current number of test failures is ~60,
>>> >> which isn't too bad. A lot of the remaining ones are STL iterator
>>> >> pickyness which should be easy to eliminate if someone sits down to
>>> >> work through them.
>>> >>
>>> >> Also, what happened with your patch to add MSVC search paths in a more
>>> >> principled fashion? In my fuzzy memory I thought it had gone in, but I
>>> >> didn't actually see it in the source.
>>> >>
>>> >> ?- Daniel
>>> >
>>> >
>>> >
>>> > --
>>> > John Thompson
>>> > John.Thompson.JTSoftware at gmail.com
>>> >
>>> >
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > cfe-dev at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> >
>>> >
>>
>>
>>
>> --
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


From clattner at apple.com  Fri Oct 16 23:05:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 16 Oct 2009 21:05:16 -0700
Subject: [cfe-dev] [LLVMdev] named address spaces
In-Reply-To: <d17b77a40910161430k60178f1k4b8dab4a5b74c463@mail.gmail.com>
References: <d17b77a40910161322g2b0053adj1ca4ce39fd0dcc37@mail.gmail.com>
	<0727CC2A-B8A7-4975-83B3-B368E27F568B@apple.com>
	<d17b77a40910161430k60178f1k4b8dab4a5b74c463@mail.gmail.com>
Message-ID: <C8641A62-4332-45B9-B07D-6C568FEF055E@apple.com>


On Oct 16, 2009, at 2:30 PM, Juan Carlos Martinez Santos wrote:

> Hello,
>
> If I want implement other address spaces (for x86), can I modify my  
> back-end (clang) to support other address spaces (at least two data  
> segments, two heaps, and two stacks?
>
> How will be the mechanism? For example, for256/257, I see two  
> reference points (FS and GP). Would I need to specify a different  
> reference to each memory region? Where is the best site to add the  
> modifications?

I don't know what changes you'll need off hand.  I think you just  
refer to them (assigning a magic number) and handle them as the come  
through the IR.

-Chris


From hans at hanshq.net  Sat Oct 17 01:24:28 2009
From: hans at hanshq.net (Hans Wennborg)
Date: Sat, 17 Oct 2009 08:24:28 +0200
Subject: [cfe-dev] [LLVMdev]  Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <4AD9631C.5080400@hanshq.net>

I was really looking forward to watching the presentation about Scalar 
Evolution, as it is something I use in my ongoing thesis work.

I cannot possibly see how Apple would benefit from this policy.

/ Hans

Chris Lattner wrote:
> On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote:
>> Hi, Chris
>>
>>> All of the videos are now up on the web page, and most of the slides
>>> are up (still need to get David's and Evan's slides).  Please let me
>>> know if you hit any problems.
>> First of all, thanks a lot about all stuff with videos & slides  
>> posting.
>>
>> I'm a bit curious: is there any reason why are other slides / videos
>> not available (it seems that the ones missing are from Apple folks)?
> 
> Unfortunately, we found out at the last minute that Apple has a rule  
> which prevents its engineers from giving video taped talks or  
> distributing slides.  We will hold onto the video and slide assets in  
> case this rule changes in the future.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From csdavec at swansea.ac.uk  Sat Oct 17 05:34:00 2009
From: csdavec at swansea.ac.uk (David Chisnall)
Date: Sat, 17 Oct 2009 11:34:00 +0100
Subject: [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <9A38B63C-16CA-4937-8EE6-F6865F5EEEF1@swan.ac.uk>

On 15 Oct 2009, at 16:45, Chris Lattner wrote:

> Unfortunately, we found out at the last minute that Apple has a rule
> which prevents its engineers from giving video taped talks or
> distributing slides.  We will hold onto the video and slide assets in
> case this rule changes in the future.

Is this a new policy?  I note that there are still videos and slides  
up from Apple developers - including yourself - from previous dev  
meetings.  If an exception was made in the past, is there a reason why  
it isn't being made again?

David

-- Send from my Jacquard Loom


From juanc.martinez.santos at gmail.com  Sat Oct 17 11:13:18 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Sat, 17 Oct 2009 12:13:18 -0400
Subject: [cfe-dev] Memory allocation in a named address space
Message-ID: <d17b77a40910170913g6a1998a7v687d2cf5255b6a51@mail.gmail.com>

Hello,

How I can allocate a chunk of memory in a named address space different than
#0 (or intrinsic)?

I tried...

#define HEAP_2 __attribute__((address_space(2)))
#include <stdlib.h>
int main() {
        int HEAP_2 *ptr = malloc(10 * sizeof (int));
        if (ptr == NULL) {
        }
        else {
                free(ptr);
                ptr = NULL;
        }
        return (1);
}

However, I got...

++++++++++++++++++++++++++++++++++++++++++++++
~/test$ <8 at emperor:~/test$> clang malloc_pift.c
malloc_pift.c:7:20: error: illegal implicit cast between two pointers with
different address spaces
        int HEAP_2 *ptr = malloc(10 * sizeof (int));
                          ^~~~~~~~~~~~~~~~~~~~~~~~~
malloc_pift.c:7:20: warning: initializing 'void *' discards qualifiers,
expected 'int __attribute__((address_space(2))) *'
        int HEAP_2 *ptr = malloc(10 * sizeof (int));
                          ^~~~~~~~~~~~~~~~~~~~~~~~~
malloc_pift.c:8:13: error: illegal implicit cast between two pointers with
different address spaces
        if (ptr == NULL) {
                   ^~~~
/home/jcmartin78/llvm/Debug/lib/clang/1.1/include/stddef.h:38:14: note:
instantiated from:
#define NULL ((void*)0)
             ^~~~~~~~~~
malloc_pift.c:11:12: error: illegal implicit cast between two pointers with
different address spaces
                free(ptr);
                     ^~~
malloc_pift.c:11:12: warning: passing 'int __attribute__((address_space(2)))
*' discards qualifiers, expected 'void *'
                free(ptr);
                     ^~~
malloc_pift.c:12:13: error: illegal implicit cast between two pointers with
different address spaces
                ptr = NULL;
                      ^~~~
/home/jcmartin78/llvm/Debug/lib/clang/1.1/include/stddef.h:38:14: note:
instantiated from:
#define NULL ((void*)0)
             ^~~~~~~~~~
6 diagnostics generated.
++++++++++++++++++++++++++++++++++++++++++++++=
 Thanks in advance,

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091017/b0409db1/attachment.html 

From eli.friedman at gmail.com  Sat Oct 17 11:38:50 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Sat, 17 Oct 2009 09:38:50 -0700
Subject: [cfe-dev] Memory allocation in a named address space
In-Reply-To: <d17b77a40910170913g6a1998a7v687d2cf5255b6a51@mail.gmail.com>
References: <d17b77a40910170913g6a1998a7v687d2cf5255b6a51@mail.gmail.com>
Message-ID: <f5aa3e9b0910170938h18164c05o209df63ca8e84fce@mail.gmail.com>

On Sat, Oct 17, 2009 at 9:13 AM, Juan Carlos Martinez Santos
<juanc.martinez.santos at gmail.com> wrote:
> Hello,
>
> How I can allocate a chunk of memory in a named address space different than
> #0 (or intrinsic)?

If you need to ask, you're probably misusing address spaces.

-Eli

From juanc.martinez.santos at gmail.com  Sat Oct 17 12:46:34 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Sat, 17 Oct 2009 13:46:34 -0400
Subject: [cfe-dev] Memory allocation in a named address space
In-Reply-To: <f5aa3e9b0910170938h18164c05o209df63ca8e84fce@mail.gmail.com>
References: <d17b77a40910170913g6a1998a7v687d2cf5255b6a51@mail.gmail.com>
	<f5aa3e9b0910170938h18164c05o209df63ca8e84fce@mail.gmail.com>
Message-ID: <d17b77a40910171046n6f7bdb4bu75e175d59c9f84d2@mail.gmail.com>

Maybe, but, what is the correct way to use the address space?

Thanks in advance,

Juan Carlos



On Sat, Oct 17, 2009 at 12:38 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Sat, Oct 17, 2009 at 9:13 AM, Juan Carlos Martinez Santos
> <juanc.martinez.santos at gmail.com> wrote:
> > Hello,
> >
> > How I can allocate a chunk of memory in a named address space different
> than
> > #0 (or intrinsic)?
>
> If you need to ask, you're probably misusing address spaces.
>
> -Eli
>



-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091017/9d5b6508/attachment.html 

From csdavec at swansea.ac.uk  Sat Oct 17 13:02:31 2009
From: csdavec at swansea.ac.uk (David Chisnall)
Date: Sat, 17 Oct 2009 19:02:31 +0100
Subject: [cfe-dev] Memory allocation in a named address space
In-Reply-To: <d17b77a40910171046n6f7bdb4bu75e175d59c9f84d2@mail.gmail.com>
References: <d17b77a40910170913g6a1998a7v687d2cf5255b6a51@mail.gmail.com>
	<f5aa3e9b0910170938h18164c05o209df63ca8e84fce@mail.gmail.com>
	<d17b77a40910171046n6f7bdb4bu75e175d59c9f84d2@mail.gmail.com>
Message-ID: <7E10EA29-ACF5-48EA-9B32-AB2BC481B879@swan.ac.uk>

The issue with your example is the use of malloc().  This is a C  
library function that (according to both LLVM semantics and the WG14  
draft for embedded C) always returns a pointer in the main address  
space.  Malloc has no argument specifying the address space.  It will  
either recycle an unused address or request memory from the OS, but  
without an argument specifying the other address space it has no way  
of knowing that you want an address anywhere other than the default  
space.

Setting the attribute on the pointer only means that this pointer may  
only point to addresses in the specified address space.  You must  
define some other mechanism for allocating memory in these spaces.   
Typically, for example, a kernel using the existing addresses that map  
to GS- and FS-relative addresses will have already defined these  
segments when it initialises the memory map.  These may be used, for  
example, for the kernel's address space, which is mapped into the  
userspace process's address space, but not visible in ring 3 (or it  
might do things the other way around, so the GS register points to the  
userspace process's segment).

Perhaps you should explain what you are actually trying to do?  Using  
different address spaces requires you to have an allocator that  
handles them and it requires the LLVM back end code to map them to  
something relevant for the architecture.  You can't just say 'this  
pointer is in address space number 47' and expect that to be meaningful.

David

On 17 Oct 2009, at 18:46, Juan Carlos Martinez Santos wrote:

> Maybe, but, what is the correct way to use the address space?
>
> Thanks in advance,
>
> Juan Carlos
>
>
>
> On Sat, Oct 17, 2009 at 12:38 PM, Eli Friedman  
> <eli.friedman at gmail.com> wrote:
> On Sat, Oct 17, 2009 at 9:13 AM, Juan Carlos Martinez Santos
> <juanc.martinez.santos at gmail.com> wrote:
> > Hello,
> >
> > How I can allocate a chunk of memory in a named address space  
> different than
> > #0 (or intrinsic)?
>
> If you need to ask, you're probably misusing address spaces.
>
> -Eli
>
>
>
> -- 
> Juan Carlos
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-- Sent from my STANTEC-ZEBRA


From lattner at apple.com  Sat Oct 17 13:51:05 2009
From: lattner at apple.com (Tanya Lattner)
Date: Sat, 17 Oct 2009 11:51:05 -0700
Subject: [cfe-dev] 2.6 pre-release2 ready for testing
Message-ID: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>

LLVMers,

2.6 pre-release2 is ready to be tested by the community.
http://llvm.org/prereleases/2.6/

If you have time, I'd appreciate anyone who can help test the release.

To test llvm-gcc:

1) Compile llvm from source and untar the llvm-test in the projects  
directory (name it llvm-test or test-suite). Choose to use a pre- 
compiled llvm-gcc or re-compile it yourself.
2) Run make check, report any failures (FAIL or unexpected pass). Note  
that you need to reconfigure llvm with llvm-gcc in your path or with -- 
with-llvmgccdir
3) Run "make TEST=nightly report" and send me the report.nightly.txt


To test clang:
1) Compile llvm and clang from source.
2) Run make check for llvm.
3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or  
unexpected passes)

When reporting your results, please provide details on what platform  
you compiled on, and how
you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.

Please COMPLETE ALL TESTING BY 5pm PDT on October 21st!

Thanks,
Tanya Lattner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091017/6943a2e0/attachment.html 

From mierle at gmail.com  Sat Oct 17 14:01:03 2009
From: mierle at gmail.com (Keir Mierle)
Date: Sat, 17 Oct 2009 12:01:03 -0700
Subject: [cfe-dev] [LLVMdev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <ef5675f30910171201j77a0ccaerd27d44e47dda4630@mail.gmail.com>

I'm pretty disappointed that the Clang and Scalar Evolution talks are not
available. I couldn't make the dev meeting this year; however, I figured the
videos and slides would still be available. Apple is sending the wrong
message; don't they want to promote the idea that LLVM is an open project
and not just Apple owned? It's silly to reinforce the fear around LLVM that
Apple will close further development.
The blanket policy enforcement is ridiculous in this case.

Keir

On Thu, Oct 15, 2009 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote:

> Hi All,
>
> All of the videos are now up on the web page, and most of the slides
> are up (still need to get David's and Evan's slides).  Please let me
> know if you hit any problems.
>
> You can access the content here:
> http://llvm.org/devmtg/2009-10/
>
> FYI, one room recorded a screencast and the other was recorded with a
> standalone camera.  This means that you can't see the speakers in one
> room, which is unfortunate but much better than no video :).
>
> I want to send a huge thanks to Jason Molenda.  Not only did he
> contribute his equipment to record the event, he also collected a
> tremendous amount of the content, edited the videos, transcoded them
> and did a lot of other great work.  Getting nice videos up takes a lot
> more work than it seems, and the video quality is very high this
> year.  Thank you Jason!
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091017/e92f2ee1/attachment.html 

From clattner at apple.com  Sat Oct 17 15:48:29 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 17 Oct 2009 13:48:29 -0700
Subject: [cfe-dev] Fwd: CodeGen/statements.c: Don't understand test and
	its failure
In-Reply-To: <aad8390910150905x4ffafd65x1ac99ffce32df63b@mail.gmail.com>
References: <aad8390910150842q5c91b383r4e8a117a21d06f4e@mail.gmail.com>
	<9BCF98C5-78B5-4808-A8C2-F6C0C55DBFDB@apple.com>
	<aad8390910150859j5602ebbag49e6d081f39ae0f2@mail.gmail.com>
	<aad8390910150905x4ffafd65x1ac99ffce32df63b@mail.gmail.com>
Message-ID: <2EC7A55A-F249-49B7-A7DA-CD813417A040@apple.com>

On Oct 15, 2009, at 9:05 AM, John Thompson wrote:
> Sorry Chris, I meant to send this to the list.

The relevant part of the dump is:
>   (DeclStmt 029B7238 <line:23:1, col:23>
>     029B70A8 "long x =
>       (ImplicitCastExpr 029B71F0 <col:10, col:20> 'long' <Unknown>
>         (BinaryOperator 029B71A0 <col:10, col:20> 'int' '-'
>           (AddrLabelExpr 029B7110 <col:10, col:12> 'void *' bar  
> 029B7068)
>           (AddrLabelExpr 029B7158 <col:18, col:20> 'void *' baz  
> 029B7028)))"
>

This case should have been fixed by r84039.  Can you verify that it  
still fails with ToT?

-Chris


>
> ---------- Forwarded message ----------
> From: John Thompson <john.thompson.jtsoftware at gmail.com>
> Date: Thu, Oct 15, 2009 at 8:59 AM
> Subject: Re: [cfe-dev] CodeGen/statements.c: Don't understand test  
> and its failure
>
>
> This is the GNU address of a label extension.  Can you remove the  
> 'static' (which will allow it to parse) and paste what clang-cc -ast- 
> dump shows for that statement?
>
>
> Thanks.  Here it is:
>
> CodeGen/statements.c:5:6: warning: integer constant is too large for  
> its type
> case 111111111111111111111111111111111111111:
>      ^
> CodeGen/statements.c:5:6: warning: overflow converting case value to  
> switch condition type (11011968431394943431 to 18446744072755114439)
> CodeGen/statements.c:11:15: warning: non-void function 'test2'  
> should return a value
> int test2() { return; }
>               ^
> CodeGen/statements.c:12:16: warning: void function 'test3' should  
> not return a value
> void test3() { return 4; }
>                ^      ~
> CodeGen/statements.c:24:17: warning: incompatible pointer to integer  
> conversion initializing 'void *', expected 'long'
> static long y = &&baz;
>                 ^~~~~
> CodeGen/statements.c:28:10: warning: incompatible integer to pointer  
> conversion passing 'long', expected 'void *'
>     goto *y;
>          ^~
> CodeGen/statements.c:30:8: warning: incompatible integer to pointer  
> conversion passing 'long', expected 'void *'
>   goto *x;
>        ^~
> CodeGen/statements.c:25:3: warning: expression result unused
>   &&bing;
>   ^~~~~~
> CodeGen/statements.c:26:3: warning: expression result unused
>   &&blong;
>   ^~~~~~~
> CodeGen/statements.c:34:31: warning: incompatible integer to pointer  
> conversion passing 'long long', expected 'void *'
> int test5(long long b) { goto *b; }
>                               ^~
> typedef char *__builtin_va_list;
> void test1(int x)
> int bar();
> int test2()
>
> void test3()
>
> void test4()
>
> int test5(long long b)
>
> (CompoundStmt 029AF2D8 <CodeGen/statements.c:3:19, line:8:1>
>   (SwitchStmt 029AEC98 <line:4:1, line:7:1>
>     (DeclRefExpr 029B0570 <line:4:9> 'int' ParmVar='x' 029B0508)
>     (CompoundStmt 029AF120 <col:12, line:7:1>
>       (CaseStmt 029AEE48 <line:5:1, line:6:5>
>         (CallExpr 029AF0A8 <col:1, col:5> 'int'
>           (ImplicitCastExpr 029AF060 <col:1> 'int (*)()'  
> <FunctionToPointerDecay>
>             (DeclRefExpr 029AEFD0 <col:1> 'int ()'  
> FunctionDecl='bar' 029AEF40)))
>         (ImplicitCastExpr 029AF1E8 <line:5:6> 'int' <Unknown>
>           (IntegerLiteral 029AEDF0 <col:6> 'unsigned long long'  
> 11011968431394943431))
>         <<<NULL>>>))))
> (CompoundStmt 029AF3F0 <CodeGen/statements.c:11:13, col:23>
>   (ReturnStmt 029AF3B0 <col:15>))
> (CompoundStmt 029AF638 <CodeGen/statements.c:12:14, col:26>
>   (ReturnStmt 029AF5F8 <col:16, col:23>
>     (IntegerLiteral 029AF5A0 <col:23> 'int' 4)))
> (CompoundStmt 029AF740 <CodeGen/statements.c:15:14, line:31:1>
>   (LabelStmt 029B7068 <line:16:1, line:20:2> 'bar'
>     (LabelStmt 029B7028 <line:17:1, line:20:2> 'baz'
>       (LabelStmt 029AF7C8 <line:18:1, line:20:2> 'blong'
>         (LabelStmt 029AF788 <line:19:1, line:20:2> 'bing'
>           (NullStmt 029AF230 <col:2>)))))
>   (DeclStmt 029B7238 <line:23:1, col:23>
>     029B70A8 "long x =
>       (ImplicitCastExpr 029B71F0 <col:10, col:20> 'long' <Unknown>
>         (BinaryOperator 029B71A0 <col:10, col:20> 'int' '-'
>           (AddrLabelExpr 029B7110 <col:10, col:12> 'void *' bar  
> 029B7068)
>           (AddrLabelExpr 029B7158 <col:18, col:20> 'void *' baz  
> 029B7028)))"
>   (DeclStmt 029B7370 <line:24:1, col:22>
>     029B7278 "static long y =
>       (ImplicitCastExpr 029B7328 <col:17, col:19> 'long' <Unknown>
>         (AddrLabelExpr 029B72E0 <col:17, col:19> 'void *' baz  
> 029B7028))"
>   (AddrLabelExpr 029B73B0 <line:25:3, col:5> 'void *' bing 029AF788)
>   (AddrLabelExpr 029B73F8 <line:26:3, col:5> 'void *' blong 029AF7C8)
>   (IfStmt 029B7558 <line:27:3, line:28:11>
>     (DeclRefExpr 029B7440 <line:27:7> 'long' Var='y' 029B7278)
>     (IndirectGotoStmt 029B7518 <line:28:5, col:11>
>       (ImplicitCastExpr 029B74D0 <col:11> 'void *' <Unknown>
>         (DeclRefExpr 029B7488 <col:11> 'long' Var='y' 029B7278)))
>     <<<NULL>>>)
>   (IndirectGotoStmt 029B7630 <line:30:3, col:9>
>     (ImplicitCastExpr 029B75E8 <col:9> 'void *' <Unknown>
>       (DeclRefExpr 029B75A0 <col:9> 'long' Var='x' 029B70A8))))
> (CompoundStmt 029AE428 <CodeGen/statements.c:34:24, col:35>
>   (IndirectGotoStmt 029B7918 <col:26, col:32>
>     (ImplicitCastExpr 029B78D0 <col:32> 'void *' <Unknown>
>       (DeclRefExpr 029B7888 <col:32> 'long long' ParmVar='b'  
> 029B7708))))
> 10 diagnostics generated.
>
>
>
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
>
>
>
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091017/eb61e853/attachment-0001.html 

From rayfix.ml at gmail.com  Sat Oct 17 19:16:31 2009
From: rayfix.ml at gmail.com (Ray Fix)
Date: Sat, 17 Oct 2009 20:16:31 -0400
Subject: [cfe-dev] patch for generalizing stdint for n-bit bytes
Message-ID: <BB76172E-1804-45DC-AB55-18EAB0F0F41F@gmail.com>


Hello Clangers,

The attached patch is the work of Ken Dyck which I merged and massaged  
a bit to work with the top of the tree (R84372).   This patch  
generalizes some of the defines produced by the preprocessor in  
preparation for future patches to support of n-bit bytes.

Some other highlights include the addition of 40 new test cases that  
help better validate the preprocessor and target defines.  It also  
gets rid of std::vector<char> in favor of llvm::raw_ostream to create  
defines.

My hope is that someone with commit authority can look these changes  
and approve them or provide feedback for any additional mods work that  
is required for them to be accepted.

Since the patch is a bit large (thanks to all of the new tests!), I am  
including a custom htmlized view of the patch.  (You might find it  
easier to grok the changes with...)

Thanks a bunch,

Ray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stdint-generalize-with-tests.patch
Type: application/octet-stream
Size: 172816 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091017/ee6baee8/attachment-0001.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091017/ee6baee8/attachment-0001.html 
-------------- next part --------------






From vadve at illinois.edu  Sat Oct 17 19:27:11 2009
From: vadve at illinois.edu (Vikram S. Adve)
Date: Sat, 17 Oct 2009 19:27:11 -0500
Subject: [cfe-dev] [LLVMdev]  Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <6C9B9561-5EFC-4095-AC74-44B6DBB8FB98@illinois.edu>


On Oct 15, 2009, at 10:45 AM, Chris Lattner wrote:

> Unfortunately, we found out at the last minute that Apple has a rule
> which prevents its engineers from giving video taped talks or
> distributing slides.  We will hold onto the video and slide assets in
> case this rule changes in the future.
>
> -Chris


Chris,

I hope you can pass my message along to the people at Apple who made  
this decision.
---

I want to request Apple to make an exception and release the videos  
and slides of presentations by Apple employees at the LLVM Developers'  
Meeting.  Several Apple employees now have a leadership role in the  
LLVM community, although LLVM remains a widely used open source  
software project.  Their presentations at the LLVM developers' meeting  
are an important component of how we help support LLVM users.  The  
presentations clearly reveal no confidential Apple information; in  
fact, they were presented in front of a large number of external  
participants.  While we appreciate Apple's continued support of LLVM  
and of the Developers' Meeting, the goodwill generated is being  
undermined by this policy to withhold important technical information  
from other LLVM users, and for little benefit to Apple.

--Vikram Adve

----------------------------------------------------------------------
  VIKRAM S. ADVE
  Associate Professor, Computer Science       E-MAIL: vadve at cs.uiuc.edu
  Siebel Center for Computer Science           PHONE:    (217) 244-2016
  Univ. of Illinois at Urbana-Champaign          FAX:    (217) 244-6500
  201 N. Goodwin Ave.
  Urbana IL 61801-2302.                          http://llvm.org/~vadve
----------------------------------------------------------------------


From rayfix.ml at gmail.com  Sat Oct 17 23:18:03 2009
From: rayfix.ml at gmail.com (Ray Fix)
Date: Sun, 18 Oct 2009 00:18:03 -0400
Subject: [cfe-dev] patch for generalizing stdint for n-bit bytes
Message-ID: <F1B39739-E93E-4E6F-B077-EB11F9D91328@gmail.com>


Hello ClangWorld,

This is a resend since my original message was too large and got  
filtered from the list.  Sorry about that;

The linked patch is the work of Ken Dyck which I merget to work with  
the top of the tree (R84372).   This patch generalizes some of the  
defines produced by the preprocessor in preparation for future patches  
to support of n-bit bytes.

Some other highlights include the addition of 40 new test cases that  
help better validate the preprocessor and target defines.  It also  
gets rid of std::vector<char> in favor of llvm::raw_ostream to create  
defines.

My hope is that someone with commit authority can look these changes  
and shepherd them in or provide feedback for any additional mods/work  
that is required for them to be accepted.

A copy of the actual .patch file is here:   http://files.me.com/rayfix/p7ouap 
       (Size: 169 kB)

Here is the same thing but rendered in html.  http://files.me.com/rayfix/5qummg 
    (Size: 300 kB)

Thanks as always,

Ray






From meurant.olivier at gmail.com  Sun Oct 18 15:25:36 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Sun, 18 Oct 2009 22:25:36 +0200
Subject: [cfe-dev] [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <549cee610910181325v6cd09955o15c2219afbed8a44@mail.gmail.com>

Hi Tanya,

glad to see that 2.6 release is coming. :)

After doing some testing with valgrind on this release, I have find a little
"undefined memory" error in DefaultJITMemoryManager related to the
PoisonMemory field.
This bug has been corrected in trunk with revision r80192.

Attached is a patch which cleanly apply same correction on the release-2.6
branch.

Thanks,
Olivier.


On Sat, Oct 17, 2009 at 8:51 PM, Tanya Lattner <lattner at apple.com> wrote:

> LLVMers,
> 2.6 pre-release2 is ready to be tested by the community.
> http://llvm.org/prereleases/2.6/
>
> If you have time, I'd appreciate anyone who can help test the release.
>
> To test llvm-gcc:
> 1) Compile llvm from source and untar the llvm-test in the projects
> directory (name it llvm-test or test-suite). Choose to use a pre-compiled
> llvm-gcc or re-compile it yourself.
> 2) Run make check, report any failures (FAIL or unexpected pass). Note that
> you need to reconfigure llvm with llvm-gcc in your path or with
> --with-llvmgccdir
> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
> To test clang:
> 1) Compile llvm and clang from source.
> 2) Run make check for llvm.
> 3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or
> unexpected passes)
>
> When reporting your results, please provide details on what platform you
> compiled on, and how
> you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.
>
> *Please COMPLETE ALL TESTING BY 5pm PDT on October 21st! *
> Thanks, Tanya Lattner
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091018/1f62abf2/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: release_2.6.patch
Type: text/x-patch
Size: 834 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091018/1f62abf2/attachment.bin 

From vgrover528 at gmail.com  Sun Oct 18 21:51:32 2009
From: vgrover528 at gmail.com (Vinod Grover)
Date: Sun, 18 Oct 2009 19:51:32 -0700
Subject: [cfe-dev] [LLVMdev]  Developer meeting videos up
In-Reply-To: <6C9B9561-5EFC-4095-AC74-44B6DBB8FB98@illinois.edu>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<6C9B9561-5EFC-4095-AC74-44B6DBB8FB98@illinois.edu>
Message-ID: <35657f570910181951u9d8c9bcud85add877fb9670a@mail.gmail.com>

I too am disappointed that not all talk slides are posted. To me it speaks
poorly of the whole meeting since there were parallel sessions and not
everyone could attend in person all the sessions they wanted to. The slides
are, I thought, meant to be like the "proceedings" and If I recall some of
the Apple slides are present from previous years but not this year.

Vinod


On Sat, Oct 17, 2009 at 5:27 PM, Vikram S. Adve <vadve at illinois.edu> wrote:

>
> On Oct 15, 2009, at 10:45 AM, Chris Lattner wrote:
>
> > Unfortunately, we found out at the last minute that Apple has a rule
> > which prevents its engineers from giving video taped talks or
> > distributing slides.  We will hold onto the video and slide assets in
> > case this rule changes in the future.
> >
> > -Chris
>
>
> Chris,
>
> I hope you can pass my message along to the people at Apple who made
> this decision.
> ---
>
> I want to request Apple to make an exception and release the videos
> and slides of presentations by Apple employees at the LLVM Developers'
> Meeting.  Several Apple employees now have a leadership role in the
> LLVM community, although LLVM remains a widely used open source
> software project.  Their presentations at the LLVM developers' meeting
> are an important component of how we help support LLVM users.  The
> presentations clearly reveal no confidential Apple information; in
> fact, they were presented in front of a large number of external
> participants.  While we appreciate Apple's continued support of LLVM
> and of the Developers' Meeting, the goodwill generated is being
> undermined by this policy to withhold important technical information
> from other LLVM users, and for little benefit to Apple.
>
> --Vikram Adve
>
> ----------------------------------------------------------------------
>   VIKRAM S. ADVE
>  Associate Professor, Computer Science       E-MAIL: vadve at cs.uiuc.edu
>  Siebel Center for Computer Science           PHONE:    (217) 244-2016
>  Univ. of Illinois at Urbana-Champaign          FAX:    (217) 244-6500
>  201 N. Goodwin Ave.
>  Urbana IL 61801-2302.                          http://llvm.org/~vadve<http://llvm.org/%7Evadve>
> ----------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091018/1058b803/attachment.html 

From lattner at apple.com  Sun Oct 18 23:12:13 2009
From: lattner at apple.com (Tanya Lattner)
Date: Sun, 18 Oct 2009 21:12:13 -0700
Subject: [cfe-dev] [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <549cee610910181325v6cd09955o15c2219afbed8a44@mail.gmail.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<549cee610910181325v6cd09955o15c2219afbed8a44@mail.gmail.com>
Message-ID: <44BF199D-5F43-4104-9482-27A994027FE2@apple.com>

Olivier,

Thanks for testing 2.6!

I'm glad this is fixed in trunk, but it will not  be applied to 2.6 at  
this stage in the release process.

Thanks,
Tanya

On Oct 18, 2009, at 1:25 PM, Olivier Meurant wrote:

> Hi Tanya,
>
> glad to see that 2.6 release is coming. :)
>
> After doing some testing with valgrind on this release, I have find  
> a little "undefined memory" error in DefaultJITMemoryManager related  
> to the PoisonMemory field.
> This bug has been corrected in trunk with revision r80192.
>
> Attached is a patch which cleanly apply same correction on the  
> release-2.6 branch.
>
> Thanks,
> Olivier.
>
>
> On Sat, Oct 17, 2009 at 8:51 PM, Tanya Lattner <lattner at apple.com>  
> wrote:
> LLVMers,
>
> 2.6 pre-release2 is ready to be tested by the community.
> http://llvm.org/prereleases/2.6/
>
> If you have time, I'd appreciate anyone who can help test the release.
>
>
> To test llvm-gcc:
> 1) Compile llvm from source and untar the llvm-test in the projects  
> directory (name it llvm-test or test-suite). Choose to use a pre- 
> compiled llvm-gcc or re-compile it yourself.
>
> 2) Run make check, report any failures (FAIL or unexpected pass).  
> Note that you need to reconfigure llvm with llvm-gcc in your path or  
> with --with-llvmgccdir
>
> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
>  To test clang:
> 1) Compile llvm and clang from source.
>
> 2) Run make check for llvm.
>  3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures  
> or unexpected passes)
>
>
> When reporting your results, please provide details on what platform  
> you compiled on, and how
>
> you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.
>
>  Please COMPLETE ALL TESTING BY 5pm PDT on October 21st!
> Thanks, Tanya Lattner
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> <release_2.6.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091018/80203ffd/attachment-0001.html 

From Olaf.Krzikalla at tu-dresden.de  Mon Oct 19 09:30:10 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Mon, 19 Oct 2009 16:30:10 +0200
Subject: [cfe-dev] MemRegions - how to (re)use them right?
In-Reply-To: <9CE3C697-E3F5-49F6-A2DD-E312C8E6CC4A@apple.com>
References: <4AC21EBD.10105@tu-dresden.de>
	<9CE3C697-E3F5-49F6-A2DD-E312C8E6CC4A@apple.com>
Message-ID: <4ADC77F2.2080500@tu-dresden.de>

Hi Ted,

it's been a while since I asked about the topic hence I appended (aka 
top-post) our conversation so far.
First, I think I need a basic flow-sensitive dataflow analysis only. 
That is, at least the code block of interest can be considered to be a 
basic block. However it might be of course embedded in for-stmts or the 
like. I looked at the graphs produced by GRExprEngine (cmd-line was 
clang-cc -analyzer-viz-egraph-graphviz -checker-cfref -analyze 
-analyzer-store=basic -analyzer-constraints=basic) but I found the 
output not very useful in the presence of loops - it seems that the 
analyzer performs some sort of simulation of the program. The graph 
contains the loop body several times (every time the index was counted 
up). In general I think GRExprEngine does too much for my purpose (at 
least at the moment).
Meanwhile I 'm able to further refine my requirements. Assume the 
following code:

void foo()
{
  for (/*...*/)  // a loop is always involved
  {
    lhs_1 = rhs_1;
    lhs_2 = rhs_2;
    //aso.
  }
}

At block level the for-body contains binary assignment expressions only. 
Now I just want to know, if and where lhs_x appears anywhere in rhs_y 
(with x < y, let's ignore x > y for the moment). Then I could expand 
rhs_y by replacing lhs_x with rhs_x, perhaps recursively. This of course 
isn't that easy as it sounds: you have to resolve things like *&a <-> a 
or a->b <-> (*a).b.
Thus all I need is a unique identifier for lhs_x and a function which 
for a given arbitrary rvalue-expression finds the referred lhs_x 
identifier (if one exists). Given these my initial example could be 
solved quite elegant:

A* ptr = &temp;                  // var ptr gets ID1
temp.a = /*expr*/;               // field var temp.a gets ID2
temp.b = /* another_expr */;     // field var temp.b gets ID3
*sink = temp.a;   // function detects ID2 for temp.a: expand to *sink = 
/*expr*/: done
*sink = ptr->b;   // function detects ID1 for ptr: expand to *sink = 
(&temp)->b:
                  // function detects ID3 for (&temp)->b: expand to 
*sink  = /* another_expr */: done

I think, that one feasible approach to do this is working on the AST 
level by unifiying expressions somehow (e.g. something like a unified 
string) and then just search for them in other unified expressions. 
However I'm afraid that this approach isn't very extensible. At least it 
means some work which possibly has been done.
OTOH I've seen the MemRegions which apparently are already designed so 
that they can act easily as these unique identifiers I mentioned above. 
Also the PostLoad node seems to designate sub-expressions for which a 
MemRegion exists. But the only clang part dealing with MemRegions so far 
is the GRExprEngine and as I said I'm note sure if it is what I need. Or 
it's me who is still not able to use GRExprEngine properly for my purpose.

What do you think? Are this or similar problems already solved, maybe by 
others?
Thanks for any help.


Best Regards
Olaf Krzikalla



Ted Kremenek schrieb:
> Hi Olaf,
>
> The short answer is "yes this can be done," and others have voiced 
> interest in doing taint analysis.
>
> At a high-level, do you want to do basic flow-sensitive dataflow 
> analysis or path-sensitive analysis?
>
> MemRegions are used by the path-sensitive dataflow engine 
> (GRExprEngine) to do a lazy abstraction of memory.  They are used in 
> combination with SVals (see SVals.h) to reason about the values of 
> expressions along a given path.  They aren't used just for 
> diagnostics, but are used to precisely reason about memory and memory 
> bindings (e.g., what value binds to a variable).
>
> If you wanted to do this using path-sensitive analysis, one way to do 
> this is to walk the ExplodedGraph produced by GRExprEngine.  The 
> ExplodedGraph represents the possible paths traced within a function, 
> and each node consists of a program location (e.g., an expression) and 
> a program state.  Specific ExplodedNodes have locations that represent 
> loads/stores.  You could "simply" walk the graph (using DFS) looking 
> for loads, and then trace where individual expression values are 
> passed to stores.  Each store consists of a location the value will be 
> stored and the value to be stored.  After a store, you keep traversing 
> the ExplodedGraph until you see a load from the same location, then 
> trace that value, etc.  There are many details to get this right, but 
> it could be done, and you wouldn't need to modify the analyzer at all.
>
> This option could be generally useful for several clients interested 
> in "taint" analysis.  Down the line we could build a simpler interface 
> to this information that layers on top of the ExplodedGraph, and have 
> the underlying machinery do all the hard work.  For example, the 
> interface would support the query that for a given Expr evaluated at 
> an ExplodedNode, what is the immediate set of preceding ExplodedNodes 
> (and corresponding Exprs) from which the value of that Expr is 
> derived.  This relation in itself is a graph that could be walked, but 
> it is at a little higher level than just walking the ExplodedGraph 
> directly.
>
> Another option is for us to build support for general "taint" tracking 
> into GRExprEngine and friends, with core transfer function logic doing 
> some of the taint propagation.  This might be useful anyway, but would 
> add more complexity not required by all clients.  It also might reduce 
> the amount of path caching done by the analyzer.
>
> On Sep 29, 2009, at 7:50 AM, Olaf Krzikalla wrote:
>
>> Hi @clang,
>>
>> I need to analyze some (rather simple) data flow at AST level. While I
>> could do it by my own I have the strange feeling that the
>> MemRegionManager already provides a lot of the means I need. However I
>> couldn't figure out how to use it. At the moment it seems to be used for
>> diagnostics only.
>> Here is a code example:
>>
>> struct A { int a, b };
>>
>> void foo(int* sink)
>> {
>>  A temp;
>>  A* ptr = &temp;
>>
>>  temp.a = /*expr*/;
>>  temp.b = /* another_expr */;
>>  *sink = temp.a;   // (1)
>>  *sink = ptr->b;   // (2)
>> }
>>
>> I want to know that at (1) actually the result of expr is written to
>> sink and that at (2) the result of another_expr is written to sink. Can
>> I somehow compute this using clang's static analyzer?
>>
>>
>> Best regards
>> Olaf Krzikalla

From cdavis at mymail.mines.edu  Mon Oct 19 09:35:12 2009
From: cdavis at mymail.mines.edu (Charles Davis)
Date: Mon, 19 Oct 2009 08:35:12 -0600
Subject: [cfe-dev] Building Wine with clang on Mac OS X 10.6
Message-ID: <4ADC7920.40309@mymail.mines.edu>

Hi,

I tried to build the latest Wine sources (the ones from git) with clang
on Mac OS X 10.6.1, and I'm encountering issues with inline functions.

Specifically, I get this message:

clang -m32 -c -I. -I. -I../../include -I../../include  -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith  -g -O2  -o interlocked.o
interlocked.c
/var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
_interlocked_cmpxchg already defined.
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)

Looking at the wine sources, I found out that interlocked_cmpxchg() is
defined "extern inline" in include/wine/port.h, and is redefined in
libs/port/interlocked.c. I suspect this is LLVM bug 2742, except that it
compiles fine with llvm-gcc.

Should I file a bug, or is this a known issue (like bug 2742)?

Thanks.

Chip


From edwintorok at gmail.com  Mon Oct 19 09:38:43 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Mon, 19 Oct 2009 17:38:43 +0300
Subject: [cfe-dev] Building Wine with clang on Mac OS X 10.6
In-Reply-To: <4ADC7920.40309@mymail.mines.edu>
References: <4ADC7920.40309@mymail.mines.edu>
Message-ID: <4ADC79F3.7050602@gmail.com>

On 2009-10-19 17:35, Charles Davis wrote:
> Hi,
>
> I tried to build the latest Wine sources (the ones from git) with clang
> on Mac OS X 10.6.1, and I'm encountering issues with inline functions.
>
> Specifically, I get this message:
>
> clang -m32 -c -I. -I. -I../../include -I../../include  -D__WINESRC__
> -D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith  -g -O2  -o interlocked.o
> interlocked.c
> /var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
> _interlocked_cmpxchg already defined.
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
>
> Looking at the wine sources, I found out that interlocked_cmpxchg() is
> defined "extern inline" in include/wine/port.h, and is redefined in
> libs/port/interlocked.c. I suspect this is LLVM bug 2742, except that it
> compiles fine with llvm-gcc.
>   

Does it compile with -std=gnu89? (clang defaults to gnu99 I think).

Best regards,
--Edwin

From cdavis at mymail.mines.edu  Mon Oct 19 10:33:01 2009
From: cdavis at mymail.mines.edu (Charles Davis)
Date: Mon, 19 Oct 2009 09:33:01 -0600
Subject: [cfe-dev] Building Wine with clang on Mac OS X 10.6
In-Reply-To: <4ADC79F3.7050602@gmail.com>
References: <4ADC7920.40309@mymail.mines.edu> <4ADC79F3.7050602@gmail.com>
Message-ID: <4ADC86AD.1070503@mymail.mines.edu>

T?r?k Edwin wrote:
> On 2009-10-19 17:35, Charles Davis wrote:
>> Hi,
>>
>> I tried to build the latest Wine sources (the ones from git) with clang
>> on Mac OS X 10.6.1, and I'm encountering issues with inline functions.
>>
>> Specifically, I get this message:
>>
>> clang -m32 -c -I. -I. -I../../include -I../../include  -D__WINESRC__
>> -D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith  -g -O2  -o interlocked.o
>> interlocked.c
>> /var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
>> _interlocked_cmpxchg already defined.
>> clang: error: assembler command failed with exit code 1 (use -v to see
>> invocation)
>>
>> Looking at the wine sources, I found out that interlocked_cmpxchg() is
>> defined "extern inline" in include/wine/port.h, and is redefined in
>> libs/port/interlocked.c. I suspect this is LLVM bug 2742, except that it
>> compiles fine with llvm-gcc.
>>   
> 
> Does it compile with -std=gnu89? (clang defaults to gnu99 I think).
> 
> Best regards,
> --Edwin
Sorry about not replying to all. (Need to get into the habit...)

Anyway, I got pretty far, but now I've encountered another "extern
inline" problem. clang complains about the redefinition of
GetProcessHeap() in dlls/kernel32/heap.c (where it was previously
defined in include/winbase.h). This is WITH -std=gnu89:

heap.c:254:15: error: redefinition of 'GetProcessHeap'
HANDLE WINAPI GetProcessHeap(void)
              ^
In file included from heap.c:59:
../../include/winbase.h:2533:29: note: previous definition is here
extern inline HANDLE WINAPI GetProcessHeap(void)
                            ^

As I said earlier (in an email some of you may not have gotten, I got a
bunch of warning diagnostics about
__attribute__((__force_align_arg_pointer__)), which, according to a
comment in include/windef.h, is supposed to ensure the stack remains
16-byte aligned. Is this needed under clang for __stdcall functions on
Mac OS X? It's apparently needed under gcc.

Speaking of __stdcall, I got some diagnostics related to
__attribute__((__stdcall__)) being used on function pointers. gcc does
not complain about this. Is this a known issue?




From kennethuil at gmail.com  Mon Oct 19 08:03:33 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Mon, 19 Oct 2009 08:03:33 -0500
Subject: [cfe-dev] [LLVMdev]  Developer meeting videos up
In-Reply-To: <35657f570910181951u9d8c9bcud85add877fb9670a@mail.gmail.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<6C9B9561-5EFC-4095-AC74-44B6DBB8FB98@illinois.edu>
	<35657f570910181951u9d8c9bcud85add877fb9670a@mail.gmail.com>
Message-ID: <400d33ea0910190603x357d6983m30efd02e6e529099@mail.gmail.com>

I've never heard of anyone forbidding their workers to distribute
videos of their non-secret-revealing talks.  Most tech companies want
to broadcast far and wide the talent of their people, and having them
give public talks and publicly distribute videos of same seems like a
good way to do that.

>> I hope you can pass my message along to the people at Apple who made
>> this decision.
>> ---
>>
>> I want to request Apple to make an exception and release the videos
>> and slides of presentations by Apple employees at the LLVM Developers'
>> Meeting. ?Several Apple employees now have a leadership role in the
>> LLVM community, although LLVM remains a widely used open source
>> software project. ?Their presentations at the LLVM developers' meeting
>> are an important component of how we help support LLVM users. ?The
>> presentations clearly reveal no confidential Apple information; in
>> fact, they were presented in front of a large number of external
>> participants. ?While we appreciate Apple's continued support of LLVM
>> and of the Developers' Meeting, the goodwill generated is being
>> undermined by this policy to withhold important technical information
>> from other LLVM users, and for little benefit to Apple.
>>
>> --Vikram Adve
>>
>> ----------------------------------------------------------------------
>> ?VIKRAM S. ADVE
>> ?Associate Professor, Computer Science ? ? ? E-MAIL: vadve at cs.uiuc.edu
>> ?Siebel Center for Computer Science ? ? ? ? ? PHONE: ? ?(217) 244-2016
>> ?Univ. of Illinois at Urbana-Champaign ? ? ? ? ?FAX: ? ?(217) 244-6500
>> ?201 N. Goodwin Ave.
>> ?Urbana IL 61801-2302. ? ? ? ? ? ? ? ? ? ? ? ? ?http://llvm.org/~vadve
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From john.thompson.jtsoftware at gmail.com  Mon Oct 19 10:51:13 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Mon, 19 Oct 2009 08:51:13 -0700
Subject: [cfe-dev] Fwd: CodeGen/statements.c: Don't understand test and
	its failure
In-Reply-To: <2EC7A55A-F249-49B7-A7DA-CD813417A040@apple.com>
References: <aad8390910150842q5c91b383r4e8a117a21d06f4e@mail.gmail.com>
	<9BCF98C5-78B5-4808-A8C2-F6C0C55DBFDB@apple.com>
	<aad8390910150859j5602ebbag49e6d081f39ae0f2@mail.gmail.com>
	<aad8390910150905x4ffafd65x1ac99ffce32df63b@mail.gmail.com>
	<2EC7A55A-F249-49B7-A7DA-CD813417A040@apple.com>
Message-ID: <aad8390910190851u54010c84u4f450aa4127109bf@mail.gmail.com>

Chris,

statements.c passes now.  Thanks!
-John
On Sat, Oct 17, 2009 at 1:48 PM, Chris Lattner <clattner at apple.com> wrote:

>   On Oct 15, 2009, at 9:05 AM, John Thompson wrote:
>
> Sorry Chris, I meant to send this to the list.
>
>
> The relevant part of the dump is:
>
>    (DeclStmt 029B7238 <line:23:1, col:23>
>     029B70A8 "long x =
>       (ImplicitCastExpr 029B71F0 <col:10, col:20> 'long' <Unknown>
>         (BinaryOperator 029B71A0 <col:10, col:20> 'int' '-'
>           (AddrLabelExpr 029B7110 <col:10, col:12> 'void *' bar 029B7068)
>           (AddrLabelExpr 029B7158 <col:18, col:20> 'void *' baz
> 029B7028)))"
>
> This case should have been fixed by r84039.  Can you verify that it still
> fails with ToT?
>
> -Chris
>
>
>
> ---------- Forwarded message ----------
> From: John Thompson <john.thompson.jtsoftware at gmail.com>
> Date: Thu, Oct 15, 2009 at 8:59 AM
> Subject: Re: [cfe-dev] CodeGen/statements.c: Don't understand test and its
> failure
>
>
>   This is the GNU address of a label extension.  Can you remove the
>> 'static' (which will allow it to parse) and paste what clang-cc -ast-dump
>> shows for that statement?
>>
>
>
> Thanks.  Here it is:
>
> CodeGen/statements.c:5:6: warning: integer constant is too large for its
> type
> case 111111111111111111111111111111111111111:
>      ^
> CodeGen/statements.c:5:6: warning: overflow converting case value to switch
> condition type (11011968431394943431 to 18446744072755114439)
> CodeGen/statements.c:11:15: warning: non-void function 'test2' should
> return a value
> int test2() { return; }
>               ^
> CodeGen/statements.c:12:16: warning: void function 'test3' should not
> return a value
> void test3() { return 4; }
>                ^      ~
> CodeGen/statements.c:24:17: warning: incompatible pointer to integer
> conversion initializing 'void *', expected 'long'
> static long y = &&baz;
>                 ^~~~~
> CodeGen/statements.c:28:10: warning: incompatible integer to pointer
> conversion passing 'long', expected 'void *'
>     goto *y;
>          ^~
> CodeGen/statements.c:30:8: warning: incompatible integer to pointer
> conversion passing 'long', expected 'void *'
>   goto *x;
>        ^~
> CodeGen/statements.c:25:3: warning: expression result unused
>   &&bing;
>   ^~~~~~
> CodeGen/statements.c:26:3: warning: expression result unused
>   &&blong;
>   ^~~~~~~
> CodeGen/statements.c:34:31: warning: incompatible integer to pointer
> conversion passing 'long long', expected 'void *'
> int test5(long long b) { goto *b; }
>                               ^~
> typedef char *__builtin_va_list;
> void test1(int x)
>
> int bar();
> int test2()
>
> void test3()
>
> void test4()
>
> int test5(long long b)
>
> (CompoundStmt 029AF2D8 <CodeGen/statements.c:3:19, line:8:1>
>   (SwitchStmt 029AEC98 <line:4:1, line:7:1>
>     (DeclRefExpr 029B0570 <line:4:9> 'int' ParmVar='x' 029B0508)
>     (CompoundStmt 029AF120 <col:12, line:7:1>
>       (CaseStmt 029AEE48 <line:5:1, line:6:5>
>         (CallExpr 029AF0A8 <col:1, col:5> 'int'
>           (ImplicitCastExpr 029AF060 <col:1> 'int (*)()'
> <FunctionToPointerDecay>
>             (DeclRefExpr 029AEFD0 <col:1> 'int ()' FunctionDecl='bar'
> 029AEF40)))
>         (ImplicitCastExpr 029AF1E8 <line:5:6> 'int' <Unknown>
>           (IntegerLiteral 029AEDF0 <col:6> 'unsigned long long'
> 11011968431394943431))
>         <<<NULL>>>))))
> (CompoundStmt 029AF3F0 <CodeGen/statements.c:11:13, col:23>
>   (ReturnStmt 029AF3B0 <col:15>))
> (CompoundStmt 029AF638 <CodeGen/statements.c:12:14, col:26>
>   (ReturnStmt 029AF5F8 <col:16, col:23>
>     (IntegerLiteral 029AF5A0 <col:23> 'int' 4)))
> (CompoundStmt 029AF740 <CodeGen/statements.c:15:14, line:31:1>
>   (LabelStmt 029B7068 <line:16:1, line:20:2> 'bar'
>     (LabelStmt 029B7028 <line:17:1, line:20:2> 'baz'
>       (LabelStmt 029AF7C8 <line:18:1, line:20:2> 'blong'
>         (LabelStmt 029AF788 <line:19:1, line:20:2> 'bing'
>           (NullStmt 029AF230 <col:2>)))))
>   (DeclStmt 029B7238 <line:23:1, col:23>
>     029B70A8 "long x =
>       (ImplicitCastExpr 029B71F0 <col:10, col:20> 'long' <Unknown>
>         (BinaryOperator 029B71A0 <col:10, col:20> 'int' '-'
>           (AddrLabelExpr 029B7110 <col:10, col:12> 'void *' bar 029B7068)
>           (AddrLabelExpr 029B7158 <col:18, col:20> 'void *' baz
> 029B7028)))"
>   (DeclStmt 029B7370 <line:24:1, col:22>
>     029B7278 "static long y =
>       (ImplicitCastExpr 029B7328 <col:17, col:19> 'long' <Unknown>
>         (AddrLabelExpr 029B72E0 <col:17, col:19> 'void *' baz 029B7028))"
>   (AddrLabelExpr 029B73B0 <line:25:3, col:5> 'void *' bing 029AF788)
>   (AddrLabelExpr 029B73F8 <line:26:3, col:5> 'void *' blong 029AF7C8)
>   (IfStmt 029B7558 <line:27:3, line:28:11>
>     (DeclRefExpr 029B7440 <line:27:7> 'long' Var='y' 029B7278)
>     (IndirectGotoStmt 029B7518 <line:28:5, col:11>
>       (ImplicitCastExpr 029B74D0 <col:11> 'void *' <Unknown>
>         (DeclRefExpr 029B7488 <col:11> 'long' Var='y' 029B7278)))
>     <<<NULL>>>)
>   (IndirectGotoStmt 029B7630 <line:30:3, col:9>
>     (ImplicitCastExpr 029B75E8 <col:9> 'void *' <Unknown>
>       (DeclRefExpr 029B75A0 <col:9> 'long' Var='x' 029B70A8))))
> (CompoundStmt 029AE428 <CodeGen/statements.c:34:24, col:35>
>   (IndirectGotoStmt 029B7918 <col:26, col:32>
>     (ImplicitCastExpr 029B78D0 <col:32> 'void *' <Unknown>
>       (DeclRefExpr 029B7888 <col:32> 'long long' ParmVar='b' 029B7708))))
> 10 diagnostics generated.
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
>
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091019/a37984ed/attachment-0001.html 

From dgregor at apple.com  Mon Oct 19 11:15:52 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 19 Oct 2009 09:15:52 -0700
Subject: [cfe-dev] Building Wine with clang on Mac OS X 10.6
In-Reply-To: <4ADC86AD.1070503@mymail.mines.edu>
References: <4ADC7920.40309@mymail.mines.edu> <4ADC79F3.7050602@gmail.com>
	<4ADC86AD.1070503@mymail.mines.edu>
Message-ID: <ACD46929-2653-4C75-B32B-E6D3F46647E0@apple.com>


On Oct 19, 2009, at 8:33 AM, Charles Davis wrote:

> T?r?k Edwin wrote:
>> On 2009-10-19 17:35, Charles Davis wrote:
>>> Hi,
>>>
>>> I tried to build the latest Wine sources (the ones from git) with  
>>> clang
>>> on Mac OS X 10.6.1, and I'm encountering issues with inline  
>>> functions.
>>>
>>> Specifically, I get this message:
>>>
>>> clang -m32 -c -I. -I. -I../../include -I../../include  -D__WINESRC__
>>> -D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith  -g -O2  -o  
>>> interlocked.o
>>> interlocked.c
>>> /var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s: 
>>> 71:FATAL:Symbol
>>> _interlocked_cmpxchg already defined.
>>> clang: error: assembler command failed with exit code 1 (use -v to  
>>> see
>>> invocation)
>>>
>>> Looking at the wine sources, I found out that interlocked_cmpxchg 
>>> () is
>>> defined "extern inline" in include/wine/port.h, and is redefined in
>>> libs/port/interlocked.c. I suspect this is LLVM bug 2742, except  
>>> that it
>>> compiles fine with llvm-gcc.
>>>
>>
>> Does it compile with -std=gnu89? (clang defaults to gnu99 I think).
>>
>> Best regards,
>> --Edwin
> Sorry about not replying to all. (Need to get into the habit...)
>
> Anyway, I got pretty far, but now I've encountered another "extern
> inline" problem. clang complains about the redefinition of
> GetProcessHeap() in dlls/kernel32/heap.c (where it was previously
> defined in include/winbase.h). This is WITH -std=gnu89:
>
> heap.c:254:15: error: redefinition of 'GetProcessHeap'
> HANDLE WINAPI GetProcessHeap(void)
>             ^
> In file included from heap.c:59:
> ../../include/winbase.h:2533:29: note: previous definition is here
> extern inline HANDLE WINAPI GetProcessHeap(void)
>                           ^

Clang does not implement this feature yet. I've filed a bug report  
about it here:

  http://llvm.org/PR5253

> As I said earlier (in an email some of you may not have gotten, I  
> got a
> bunch of warning diagnostics about
> __attribute__((__force_align_arg_pointer__)), which, according to a
> comment in include/windef.h, is supposed to ensure the stack remains
> 16-byte aligned. Is this needed under clang for __stdcall functions on
> Mac OS X? It's apparently needed under gcc.

We don't have support for this attribute in Clang, and I don't know  
whether it is necessary for what you're doing. Please file an  
extension request at

	http://llvm.org/bugs/

> Speaking of __stdcall, I got some diagnostics related to
> __attribute__((__stdcall__)) being used on function pointers. gcc does
> not complain about this. Is this a known issue?

Not one I know about. What diagnostics on what code?

	- Doug

From cdavis at mymail.mines.edu  Mon Oct 19 11:22:01 2009
From: cdavis at mymail.mines.edu (Charles Davis)
Date: Mon, 19 Oct 2009 10:22:01 -0600
Subject: [cfe-dev] Building Wine with clang on Mac OS X 10.6
In-Reply-To: <ACD46929-2653-4C75-B32B-E6D3F46647E0@apple.com>
References: <4ADC7920.40309@mymail.mines.edu> <4ADC79F3.7050602@gmail.com>
	<4ADC86AD.1070503@mymail.mines.edu>
	<ACD46929-2653-4C75-B32B-E6D3F46647E0@apple.com>
Message-ID: <4ADC9229.2080900@mymail.mines.edu>

Douglas Gregor wrote:
> 
> On Oct 19, 2009, at 8:33 AM, Charles Davis wrote:
> 
>> T?r?k Edwin wrote:
>>> On 2009-10-19 17:35, Charles Davis wrote:
>>>> Hi,
>>>>
>>>> I tried to build the latest Wine sources (the ones from git) with clang
>>>> on Mac OS X 10.6.1, and I'm encountering issues with inline functions.
>>>>
>>>> Specifically, I get this message:
>>>>
>>>> clang -m32 -c -I. -I. -I../../include -I../../include  -D__WINESRC__
>>>> -D_REENTRANT -fPIC -Wall -pipe -Wpointer-arith  -g -O2  -o
>>>> interlocked.o
>>>> interlocked.c
>>>> /var/folders/Vv/Vvv1iGUYFBiWfsCkpG71-U+++TI/-Tmp-/cc-XxETkM.s:71:FATAL:Symbol
>>>>
>>>> _interlocked_cmpxchg already defined.
>>>> clang: error: assembler command failed with exit code 1 (use -v to see
>>>> invocation)
>>>>
>>>> Looking at the wine sources, I found out that interlocked_cmpxchg() is
>>>> defined "extern inline" in include/wine/port.h, and is redefined in
>>>> libs/port/interlocked.c. I suspect this is LLVM bug 2742, except
>>>> that it
>>>> compiles fine with llvm-gcc.
>>>>
>>>
>>> Does it compile with -std=gnu89? (clang defaults to gnu99 I think).
>>>
>>> Best regards,
>>> --Edwin
>> Sorry about not replying to all. (Need to get into the habit...)
>>
>> Anyway, I got pretty far, but now I've encountered another "extern
>> inline" problem. clang complains about the redefinition of
>> GetProcessHeap() in dlls/kernel32/heap.c (where it was previously
>> defined in include/winbase.h). This is WITH -std=gnu89:
>>
>> heap.c:254:15: error: redefinition of 'GetProcessHeap'
>> HANDLE WINAPI GetProcessHeap(void)
>>             ^
>> In file included from heap.c:59:
>> ../../include/winbase.h:2533:29: note: previous definition is here
>> extern inline HANDLE WINAPI GetProcessHeap(void)
>>                           ^
> 
> Clang does not implement this feature yet. I've filed a bug report about
> it here:
> 
>  http://llvm.org/PR5253
OK.
> 
>> As I said earlier (in an email some of you may not have gotten, I got a
>> bunch of warning diagnostics about
>> __attribute__((__force_align_arg_pointer__)), which, according to a
>> comment in include/windef.h, is supposed to ensure the stack remains
>> 16-byte aligned. Is this needed under clang for __stdcall functions on
>> Mac OS X? It's apparently needed under gcc.
> 
> We don't have support for this attribute in Clang, and I don't know
> whether it is necessary for what you're doing. Please file an extension
> request at
> 
>     http://llvm.org/bugs/
You don't? Well then, I guess, to be on the safe side, I should file a
request.
> 
>> Speaking of __stdcall, I got some diagnostics related to
>> __attribute__((__stdcall__)) being used on function pointers. gcc does
>> not complain about this. Is this a known issue?
> 
> Not one I know about. What diagnostics on what code?
Basically, any code that defines a __stdcall function pointer typedef,
like this one for example:

../../include/winnt.h:5034:15: warning: '__stdcall__' attribute only
applies to
function types
typedef VOID (NTAPI * PFLS_CALLBACK_FUNCTION) ( PVOID );
              ^
../../include/winnt.h:44:15: note: instantiated from:
#define NTAPI __stdcall
              ^../../include/windef.h:57:38: note: instantiated from:
#    define __stdcall __attribute__((__stdcall__))
__attribute__((__force_align_
arg_pointer__))                                     ^


> 
>     - Doug

Thanks.

Chip



From Ken.Dyck at onsemi.com  Mon Oct 19 13:30:09 2009
From: Ken.Dyck at onsemi.com (Ken Dyck)
Date: Mon, 19 Oct 2009 11:30:09 -0700
Subject: [cfe-dev] patch for generalizing stdint for n-bit bytes
In-Reply-To: <BB76172E-1804-45DC-AB55-18EAB0F0F41F@gmail.com>
References: <BB76172E-1804-45DC-AB55-18EAB0F0F41F@gmail.com>
Message-ID: <8F2E4A8BCDA0B84DA6C9088EB5B27747844567@NAMAIL.ad.onsemi.com>

On Saturday, October 17, 2009 8:17 PM, Ray wrote:
> This patch generalizes some of the defines produced by the 
> preprocessor in preparation for future patches to support of 
> n-bit bytes.

Specifically, it adds support to stdint.h for all mutiple-of-8 integer
widths up to 64 bits, where it previously only supported 8-, 16-, 32-
and 64-bit widths.

> Some other highlights include the addition of 40 new test 
> cases that help better validate the preprocessor and target 
> defines.  It also gets rid of std::vector<char> in favor of 
> llvm::raw_ostream to create defines.

If it helps, I'd be happy to separate the new test cases and the
raw_ostream conversion into separate patches. 

-Ken


From john.thompson.jtsoftware at gmail.com  Mon Oct 19 14:14:16 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Mon, 19 Oct 2009 12:14:16 -0700
Subject: [cfe-dev] Selector::getAsString problem in CIndex
Message-ID: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>

I'm looking at a test failure of c-index-api-test.m on Windows, and I've run
into a problem I don't know how to easily fix.

In the function Selector::getAsString function in IdentifierTable.cpp at
line 330:

    return II->getName().str() + ":";

On Windows, at least, this isn't working as expected.  I think
it's because a tempory string created gets destructed before the return
completes, causing the resulting string pointer to point to garbage,
resulting in garbage for the identifier name in the index output.

If someone more knowlegeable about it could take a look at it, I'd
appreciate it.

Note that if you need to run it on windows, you'll need some CIndex changes
I'm working on, but haven't completed yet, so let me know if you need them.

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091019/a30d599a/attachment.html 

From holm at liacs.nl  Mon Oct 19 16:28:12 2009
From: holm at liacs.nl (Mattias Holm)
Date: Mon, 19 Oct 2009 23:28:12 +0200
Subject: [cfe-dev] ext_vector_type cg-gen crash on x86-64 and some questions
 on the ABI
Message-ID: <hbilld$qv4$1@ger.gmane.org>

I have some code that simplified is:

///////////////////////////////
#include <math.h>
#include <stdint.h>

#if __has_feature(attribute_ext_vector_type)
typedef float __attribute__((ext_vector_type (3))) float3;
typedef int32_t __attribute__((ext_vector_type (3))) int3;
typedef union float3_u {
   float3 v;
   float a[3];
} float3_u;
#endif

struct lwcoord {
   float3 offs;
   int3 seg;
};
static  float3
vf3_set(float x, float y, float z)
{
   float3_u uc = {.a = {x,y,z}};
   return uc.v;
}
static  int3
vi3_set(int32_t a, int32_t b, int32_t c)
{
   union {
     int3 v;
     struct {
       int32_t x, y, z;
     } s;
   } u;

   u.s.x = a;
   u.s.y = b;
   u.s.z = c;

   return u.v;
}

typedef struct lwcoord lwcoord;

void
lwc_set(lwcoord *coord, float x, float y, float z)
{
   coord->offs = vf3_set(x, y, z);
   coord->seg = vi3_set(0, 0, 0); // Remove this and it compiles
}

///////////////////////////////

Compiling this for x86-64 results in the following crash (using the 
clang version distributed with Snow Leopard).

1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'X86 DAG->DAG Instruction Selection' on function '@lwc_set'


It compiles fine with x86 (32 bit).

It also seems to be fine if you remove the vi3_set line, but not if you 
remove the vf3_set line.

Now some questions on the semantics of the ext_vector_type, since it is 
not that well documented in the clang extensions page.

1. What is the ABI for an ext_vector_type? Will the vectors be passed in 
SSE registers if they are passed as function arguments, or will they be 
passed by address?
2. Sizeof (float3) returns 12 and not 16 as I would have guessed for 
alignment reasons, why is this the case? Assuming you want to use SSE 
for computing with the vectors, they must be aligned IIRC.


Regards,
Mattias


From daniel at zuster.org  Mon Oct 19 16:48:08 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Mon, 19 Oct 2009 14:48:08 -0700
Subject: [cfe-dev] patch for generalizing stdint for n-bit bytes
In-Reply-To: <8F2E4A8BCDA0B84DA6C9088EB5B27747844567@NAMAIL.ad.onsemi.com>
References: <BB76172E-1804-45DC-AB55-18EAB0F0F41F@gmail.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B27747844567@NAMAIL.ad.onsemi.com>
Message-ID: <6a8523d60910191448i3cbe3eam928a2fd8ee32d98f@mail.gmail.com>

On Mon, Oct 19, 2009 at 11:30 AM, Ken Dyck <Ken.Dyck at onsemi.com> wrote:
> On Saturday, October 17, 2009 8:17 PM, Ray wrote:
>> This patch generalizes some of the defines produced by the
>> preprocessor in preparation for future patches to support of
>> n-bit bytes.
>
> Specifically, it adds support to stdint.h for all mutiple-of-8 integer
> widths up to 64 bits, where it previously only supported 8-, 16-, 32-
> and 64-bit widths.
>
>> Some other highlights include the addition of 40 new test
>> cases that help better validate the preprocessor and target
>> defines. ?It also gets rid of std::vector<char> in favor of
>> llvm::raw_ostream to create defines.
>
> If it helps, I'd be happy to separate the new test cases and the
> raw_ostream conversion into separate patches.

Hi Ken,

Yes, that would probably be very helpful!

 - Daniel


From kremenek at apple.com  Mon Oct 19 19:05:29 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Mon, 19 Oct 2009 17:05:29 -0700
Subject: [cfe-dev] test/CodeGenCXX/references.cpp failing for i386
Message-ID: <EBB5BC2C-0772-4E95-9AD0-37B7D082A876@apple.com>

One of the Clang tests is failing when the target architecture is  
i386.  For 'test/CodeGenCXX/references.cpp', we get different results  
depending on whether the target architecture (which for this test is  
determined by the host) is i386 or x86_64:

  $ clang-cc -verify -emit-llvm -o - references.cpp -triple i386-apple- 
darwin10 | FileCheck references.cpp
  references.cpp:124:34: error: expected string not found in input
   // CHECK: call void @_ZN1T1B1fEv
                                   ^
  <stdin>:245:24: note: scanning from here
   call void @_ZN1T1BC1Ev(%struct.A* %tmp) ssp
                         ^

VERSUS

  $ clang-cc -verify -emit-llvm -o - references.cpp -triple x86_64- 
apple-darwin10 | FileCheck references.cpp

Does this look familiar to anyone?  Notice the small differences in  
the 'call' instruction.  If this test needs to be made architecture  
specific, we should add a '-triple' option to the test.

From andersca at mac.com  Mon Oct 19 19:12:18 2009
From: andersca at mac.com (Anders Carlsson)
Date: Mon, 19 Oct 2009 17:12:18 -0700
Subject: [cfe-dev] test/CodeGenCXX/references.cpp failing for i386
In-Reply-To: <EBB5BC2C-0772-4E95-9AD0-37B7D082A876@apple.com>
References: <EBB5BC2C-0772-4E95-9AD0-37B7D082A876@apple.com>
Message-ID: <753994C0-9EF2-4BE4-A21A-7E64424D3F84@mac.com>

Hi Ted,

I caused this - I'll add a triple for now.

Anders


19 okt 2009 kl. 17.05 skrev Ted Kremenek:

> One of the Clang tests is failing when the target architecture is
> i386.  For 'test/CodeGenCXX/references.cpp', we get different results
> depending on whether the target architecture (which for this test is
> determined by the host) is i386 or x86_64:
>
>  $ clang-cc -verify -emit-llvm -o - references.cpp -triple i386-apple-
> darwin10 | FileCheck references.cpp
>  references.cpp:124:34: error: expected string not found in input
>   // CHECK: call void @_ZN1T1B1fEv
>                                   ^
>  <stdin>:245:24: note: scanning from here
>   call void @_ZN1T1BC1Ev(%struct.A* %tmp) ssp
>                         ^
>
> VERSUS
>
>  $ clang-cc -verify -emit-llvm -o - references.cpp -triple x86_64-
> apple-darwin10 | FileCheck references.cpp
>
> Does this look familiar to anyone?  Notice the small differences in
> the 'call' instruction.  If this test needs to be made architecture
> specific, we should add a '-triple' option to the test.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From kremenek at apple.com  Mon Oct 19 19:19:10 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Mon, 19 Oct 2009 17:19:10 -0700
Subject: [cfe-dev] test/CodeGenCXX/references.cpp failing for i386
In-Reply-To: <753994C0-9EF2-4BE4-A21A-7E64424D3F84@mac.com>
References: <EBB5BC2C-0772-4E95-9AD0-37B7D082A876@apple.com>
	<753994C0-9EF2-4BE4-A21A-7E64424D3F84@mac.com>
Message-ID: <BB016E67-7581-4A68-B5E2-FE97876FE565@apple.com>

Thanks Anders!

On Oct 19, 2009, at 5:12 PM, Anders Carlsson wrote:

> Hi Ted,
>
> I caused this - I'll add a triple for now.
>
> Anders
>
>
> 19 okt 2009 kl. 17.05 skrev Ted Kremenek:
>
>> One of the Clang tests is failing when the target architecture is
>> i386.  For 'test/CodeGenCXX/references.cpp', we get different results
>> depending on whether the target architecture (which for this test is
>> determined by the host) is i386 or x86_64:
>>
>> $ clang-cc -verify -emit-llvm -o - references.cpp -triple i386-apple-
>> darwin10 | FileCheck references.cpp
>> references.cpp:124:34: error: expected string not found in input
>>  // CHECK: call void @_ZN1T1B1fEv
>>                                  ^
>> <stdin>:245:24: note: scanning from here
>>  call void @_ZN1T1BC1Ev(%struct.A* %tmp) ssp
>>                        ^
>>
>> VERSUS
>>
>> $ clang-cc -verify -emit-llvm -o - references.cpp -triple x86_64-
>> apple-darwin10 | FileCheck references.cpp
>>
>> Does this look familiar to anyone?  Notice the small differences in
>> the 'call' instruction.  If this test needs to be made architecture
>> specific, we should add a '-triple' option to the test.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From jay.foad at gmail.com  Tue Oct 20 06:24:00 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Tue, 20 Oct 2009 12:24:00 +0100
Subject: [cfe-dev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <ee2e06e90910200424y224e068bq557ad368bf5bc4b9@mail.gmail.com>

> 2.6 pre-release2 is ready to be tested by the community.

Excellent! Would you care to update the "LLVM 2.6 release schedule" on
the front page of the web site?

Thanks,
Jay.

From baldrick at free.fr  Tue Oct 20 08:02:12 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 15:02:12 +0200
Subject: [cfe-dev] [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <4ADDB4D4.5010504@free.fr>

Hi Tanya,

> 1) Compile llvm from source and untar the llvm-test in the projects 
> directory (name it llvm-test or test-suite). Choose to use a 
> pre-compiled llvm-gcc or re-compile it yourself.

I compiled llvm and llvm-gcc with separate objects directories.
Platform is x86_64-linux-gnu.

> 2) Run make check, report any failures (FAIL or unexpected pass). Note 
> that you need to reconfigure llvm with llvm-gcc in your path or with 
> --with-llvmgccdir

One failure:

FAIL: llvm-2.6/llvm-2.6/test/Feature/load_module.ll for PR1318
Failed with exit(1) at line 1
while running:  llvm-as < llvm-2.6/llvm-2.6/test/Feature/load_module.ll 
|  opt -load=llvm-2.6/llvm-2.6-objects/Release/lib/LLVMHello.so -hello 
-disable-output - |& /bin/grep Hello
Error opening 'llvm-2.6-objects/Release/lib/LLVMHello.so': 
llvm-2.6-objects/Release/lib/LLVMHello.so: undefined symbol: _ZN4llvm4cerrE
child process exited abnormally

One unexpected pass:

XPASS: 
llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c

> 3) Run "make TEST=nightly report" and send me the report.nightly.txt

Attached.

Ciao,

Duncan.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.nightly.txt
Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/20c8f18b/attachment-0001.txt 

From john.thompson.jtsoftware at gmail.com  Tue Oct 20 10:03:41 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 20 Oct 2009 08:03:41 -0700
Subject: [cfe-dev] Selector::getAsString problem in CIndex
In-Reply-To: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>
References: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>
Message-ID: <aad8390910200803v2d598a97y6fad4fccf592e198@mail.gmail.com>

Now that I have electricity again...

Sorry, I was looking too deep, not noticing that the function returned a
std::string.  The problem was up higher in CIndex.cpp, in a couple of the
functions that return const char *, with the same problem I described of the
temporary going away before the string can be used.

I worked around it by using a static buffer, which is admittedly not so
good.  A cleaner way might be to have the user pass in a string buffer,
since it seems this needs to be a C interface.  Should I do that, or does
the API need to remain unchanged?  Let me know if there's a better way.

The enclosed patch contains my hacked version, which also includes the DLL
exporting glue (redone in the naming style I'm used to - apologies to Jeff
Krall, who'd already done it).

Note that I moved the getLocationFromCursor function out of the extern "C"
{} because MSVC was complaining about it because of the object return type.

Where does "basename" come from on the non-Windows platforms?  It was
unresolved, so I guessed at it, but which seems to work.

The c-index-api-test.m test passes on Windows with these changes.

-John
On Mon, Oct 19, 2009 at 12:14 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> I'm looking at a test failure of c-index-api-test.m on Windows, and I've
> run into a problem I don't know how to easily fix.
>
> In the function Selector::getAsString function in IdentifierTable.cpp at
> line 330:
>
>     return II->getName().str() + ":";
>
> On Windows, at least, this isn't working as expected.  I think
> it's because a tempory string created gets destructed before the return
> completes, causing the resulting string pointer to point to garbage,
> resulting in garbage for the identifier name in the index output.
>
> If someone more knowlegeable about it could take a look at it, I'd
> appreciate it.
>
> Note that if you need to run it on windows, you'll need some CIndex changes
> I'm working on, but haven't completed yet, so let me know if you need them.
>
> -John
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/a12482bb/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cindex.patch
Type: application/octet-stream
Size: 14751 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/a12482bb/attachment.obj 

From snaroff at apple.com  Tue Oct 20 10:36:29 2009
From: snaroff at apple.com (steve naroff)
Date: Tue, 20 Oct 2009 11:36:29 -0400
Subject: [cfe-dev] Selector::getAsString problem in CIndex
In-Reply-To: <aad8390910200803v2d598a97y6fad4fccf592e198@mail.gmail.com>
References: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>
	<aad8390910200803v2d598a97y6fad4fccf592e198@mail.gmail.com>
Message-ID: <AC3E6E17-6F34-453D-9661-74FE887829A3@apple.com>

Hi John,

Comments below...

On Oct 20, 2009, at 11:03 AM, John Thompson wrote:

> Now that I have electricity again...
>
> Sorry, I was looking too deep, not noticing that the function  
> returned a std::string.  The problem was up higher in CIndex.cpp, in  
> a couple of the functions that return const char *, with the same  
> problem I described of the temporary going away before the string  
> can be used.
>

Nice catch. I guess other platforms are more forgiving...

> I worked around it by using a static buffer, which is admittedly not  
> so good.  A cleaner way might be to have the user pass in a string  
> buffer, since it seems this needs to be a C interface.  Should I do  
> that, or does the API need to remain unchanged?  Let me know if  
> there's a better way.
>

I'd like to avoid cluttering the interface if possible. I'm not an  
expert on std::String, so I'll have to look into this. I'll get back  
to you...

> The enclosed patch contains my hacked version, which also includes  
> the DLL exporting glue (redone in the naming style I'm used to -  
> apologies to Jeff Krall, who'd already done it).
>

Can you separate this from the other stuff in the patch? I'd like to  
keep this type of mechanical change separate from the trickier stuff...

> Note that I moved the getLocationFromCursor function out of the  
> extern "C" {} because MSVC was complaining about it because of the  
> object return type.
>
> Where does "basename" come from on the non-Windows platforms?  It  
> was unresolved, so I guessed at it, but which seems to work.
>

basename is a Unix/Linux function...not standard C or POSIX. Does  
Windows have something called _splitpath()?

> The c-index-api-test.m test passes on Windows with these changes.

Great. Thanks for helping out on this!

snaroff

>
> -John
> On Mon, Oct 19, 2009 at 12:14 PM, John Thompson <john.thompson.jtsoftware at gmail.com 
> > wrote:
> I'm looking at a test failure of c-index-api-test.m on Windows, and  
> I've run into a problem I don't know how to easily fix.
>
> In the function Selector::getAsString function in  
> IdentifierTable.cpp at line 330:
>
>     return II->getName().str() + ":";
>
> On Windows, at least, this isn't working as expected.  I think it's  
> because a tempory string created gets destructed before the return  
> completes, causing the resulting string pointer to point to garbage,  
> resulting in garbage for the identifier name in the index output.
>
> If someone more knowlegeable about it could take a look at it, I'd  
> appreciate it.
>
> Note that if you need to run it on windows, you'll need some CIndex  
> changes I'm working on, but haven't completed yet, so let me know if  
> you need them.
>
> -John
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
>
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> <cindex.patch>_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/c73310be/attachment-0001.html 

From lattner at apple.com  Tue Oct 20 12:46:12 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 20 Oct 2009 10:46:12 -0700
Subject: [cfe-dev] 2.6 pre-release2 ready for testing
In-Reply-To: <ee2e06e90910200424y224e068bq557ad368bf5bc4b9@mail.gmail.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<ee2e06e90910200424y224e068bq557ad368bf5bc4b9@mail.gmail.com>
Message-ID: <DAA140A2-6E4F-40AC-B954-EAD2A0511B55@apple.com>


On Oct 20, 2009, at 4:24 AM, Jay Foad wrote:

>> 2.6 pre-release2 is ready to be tested by the community.
>
> Excellent! Would you care to update the "LLVM 2.6 release schedule" on
> the front page of the web site?
>

Yes. But as always, its an estimate. It depends on the outcome of the  
testing.

-Tanya

> Thanks,
> Jay.


From lattner at apple.com  Tue Oct 20 12:59:14 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 20 Oct 2009 10:59:14 -0700
Subject: [cfe-dev] [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <4ADDB4D4.5010504@free.fr>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<4ADDB4D4.5010504@free.fr>
Message-ID: <81F09A6F-7488-4845-9D02-12DA0211D5CF@apple.com>


On Oct 20, 2009, at 6:02 AM, Duncan Sands wrote:

> Hi Tanya,
>
>> 1) Compile llvm from source and untar the llvm-test in the projects  
>> directory (name it llvm-test or test-suite). Choose to use a pre- 
>> compiled llvm-gcc or re-compile it yourself.
>
> I compiled llvm and llvm-gcc with separate objects directories.
> Platform is x86_64-linux-gnu.
>

Ok.


>> 2) Run make check, report any failures (FAIL or unexpected pass).  
>> Note that you need to reconfigure llvm with llvm-gcc in your path  
>> or with --with-llvmgccdir
>
> One failure:
>
> FAIL: llvm-2.6/llvm-2.6/test/Feature/load_module.ll for PR1318
> Failed with exit(1) at line 1
> while running:  llvm-as < llvm-2.6/llvm-2.6/test/Feature/ 
> load_module.ll |  opt -load=llvm-2.6/llvm-2.6-objects/Release/lib/ 
> LLVMHello.so -hello -disable-output - |& /bin/grep Hello
> Error opening 'llvm-2.6-objects/Release/lib/LLVMHello.so': llvm-2.6- 
> objects/Release/lib/LLVMHello.so: undefined symbol: _ZN4llvm4cerrE
> child process exited abnormally
>

Did you compile llvm with llvm-gcc? This is exactly PR4849.

> One unexpected pass:
>
> XPASS: llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11- 
> AsmBlocksComplexJumpTarget.c
>

Does using the llvm-gcc binary for x86_64 produce the same results for  
this test?

>> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
> Attached.
>

This seemed to be inlined into the mail instead of attached. Can you  
send again?

Thanks,
Tanya

> Ciao,
>
> Duncan.
> Program 
>                                                                   |  
> GCCAS  Bytecode LLC compile LLC-BETA compile JIT codegen | GCC      
> CBE     LLC     LLC-BETA JIT     | GCC/CBE GCC/LLC GCC/LLC-BETA LLC/ 
> LLC-BETA
> MultiSource/Applications/Burg/ 
> burg                                       | 0.4400 112068    
> 0.9899      *                1.0100      |    0.00    0.00    0.01  
> *           1.06 | -       -       n/a          n/a
> MultiSource/Applications/ClamAV/ 
> clamscan                                 | 4.7699 1321972   
> 8.1600      *                4.5900      |    0.37 *          0.21  
> *           4.98 | n/a     1.76    n/a          n/a
> MultiSource/Applications/JM/ldecod/ 
> ldecod                                | 2.6799 664468   3.1200       
> *                2.5700      |    0.12    0.11    0.12 *            
> 2.82 | 1.09    1.00    n/a          n/a
> MultiSource/Applications/JM/lencod/ 
> lencod                                | 5.6600 1462632  7.7899       
> *                6.5999      |    9.73    9.01    8.99 *           
> 16.29 | 1.08    1.08    n/a          n/a
> MultiSource/Applications/SIBsim4/ 
> SIBsim4                                 | 0.4700 88500     
> 0.5400      *                0.5399      |    4.91 *          4.55  
> *           5.41 | n/a     1.08    n/a          n/a
> MultiSource/Applications/SPASS/ 
> SPASS                                     | 6.5800 1603628   
> 6.6600      *                4.6100      |   10.54   10.00    9.98  
> *          15.63 | 1.05    1.06    n/a          n/a
> MultiSource/Applications/aha/ 
> aha                                         | 0.0499 7356      
> 0.0300      *                0.0500      |    3.23    2.97    2.78  
> *           3.26 | 1.09    1.16    n/a          n/a
> MultiSource/Applications/d/ 
> make_dparser                                  | 1.1100 311092    
> 1.1700      *                1.0100      |    0.03 *          0.03  
> *           1.14 | n/a     -       n/a          n/a
> MultiSource/Applications/hbd/ 
> hbd                                         | 0.2500 82224     
> 0.3999      *                0.3400      |    0.00    0.00    0.00  
> *           0.39 | -       -       n/a          n/a
> MultiSource/Applications/hexxagon/ 
> hexxagon                               | 0.2000 49988    0.2600       
> *                0.2399      |   12.80    9.91    9.62 *            
> 9.42 | 1.29    1.33    n/a          n/a
> 			llc: /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
> CBackend.cpp:488:  
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
> (llvm::formatted_raw_ostream&, const llvm::Type*, bool, const  
> std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not  
> implemented yet"' failed.
> MultiSource/Applications/kimwitu++/ 
> kc                                    | 5.7400 1722276  8.1900       
> *                5.5100      |    0.18 *          0.14 *            
> 6.17 | n/a     1.29    n/a          n/a
> MultiSource/Applications/lambda-0.1.3/ 
> lambda                             | 0.2100 66708    0.4300       
> *                0.3199      |    5.30    5.31    5.36 *            
> 6.34 | 1.00    0.99    n/a          n/a
> MultiSource/Applications/lemon/ 
> lemon                                     | 0.4200 108608    
> 0.6300      *                0.0100      |    0.07    0.07    0.06  
> *         133.28 | -       -       n/a          n/a
> MultiSource/Applications/lua/ 
> lua                                         | 1.7100 547448    
> 2.8600      *                2.0899      |   27.89 *         27.87  
> *          30.62 | n/a     1.00    n/a          n/a
> MultiSource/Applications/minisat/ 
> minisat                                 | 0.2800 47664     
> 0.2700      *                *           |    8.31 *          8.28  
> *        *       | n/a     1.00    n/a          n/a
> MultiSource/Applications/obsequi/ 
> Obsequi                                 | 0.3600 61068     
> 0.3499      *                0.3200      |    2.55 *          2.48  
> *           3.00 | n/a     1.03    n/a          n/a
> MultiSource/Applications/oggenc/ 
> oggenc                                   | 1.5600 815432    
> 1.3699      *                1.1900      |    0.19 *          0.18  
> *           1.50 | n/a     1.06    n/a          n/a
> MultiSource/Applications/sgefa/ 
> sgefa                                     | 0.1200 17048     
> 0.1099      *                0.1199      |    0.84    0.85    0.84  
> *           1.00 | 0.99    1.00    n/a          n/a
> MultiSource/Applications/siod/ 
> siod                                       | 0.7600 344780    
> 2.4000      *                0.9599      |    3.46    3.25    3.42  
> *           4.62 | 1.06    1.01    n/a          n/a
> MultiSource/Applications/spiff/ 
> spiff                                     | 0.2000 51480     
> 0.3100      *                *           |    0.94    0.93    0.96  
> *        *       | 1.01    0.98    n/a          n/a
> MultiSource/Applications/sqlite3/ 
> sqlite3                                 | 3.6800 1139780   
> 6.3700      *                4.6300      |    5.10 *          5.15  
> *          10.40 | n/a     0.99    n/a          n/a
> MultiSource/Applications/treecc/ 
> treecc                                   | 0.7200 287712    
> 1.5700      *                0.4299      |    0.00    0.00    0.00  
> *           0.47 | -       -       n/a          n/a
> MultiSource/Applications/viterbi/ 
> viterbi                                 | 0.0499 5460      
> 0.0400      *                0.0300      |   11.62   11.68   11.81  
> *          11.87 | 0.99    0.98    n/a          n/a
> MultiSource/Benchmarks/ASCI_Purple/SMG2000/ 
> smg2000                       | 2.9899 498940   3.0500       
> *                2.2999      |    4.51    4.23    4.44 *            
> 6.71 | 1.07    1.02    n/a          n/a
> MultiSource/Benchmarks/ASC_Sequoia/AMGmk/ 
> AMGmk                           | 0.0999 14168    0.0800       
> *                0.0799      |   15.60   15.84   15.72 *           
> 15.78 | 0.98    0.99    n/a          n/a
> MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/ 
> CrystalMk                   | 0.0500 8296     0.0500       
> *                0.0300      |    8.83    8.73    8.69 *            
> 8.77 | 1.01    1.02    n/a          n/a
> MultiSource/Benchmarks/ASC_Sequoia/IRSmk/ 
> IRSmk                           | 0.0100 5600     0.0300       
> *                0.0300      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/BitBench/drop3/ 
> drop3                              | 0.0200 3592     0.0199       
> *                0.0200      |    0.48    0.66    0.46 *            
> 0.49 | 0.73    1.04    n/a          n/a
> MultiSource/Benchmarks/BitBench/five11/ 
> five11                            | 0.0000 2768     0.0100       
> *                0.0100      |    2.33    2.44    2.27 *            
> 2.39 | 0.95    1.03    n/a          n/a
> MultiSource/Benchmarks/BitBench/uudecode/ 
> uudecode                        | 0.0200 2968     0.0100       
> *                0.0000      |    0.13    0.12    0.14 *            
> 0.14 | 1.08    0.93    n/a          n/a
> MultiSource/Benchmarks/BitBench/uuencode/ 
> uuencode                        | 0.0200 2764     0.0200       
> *                0.0100      |    0.00    0.01    0.00 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/Fhourstones-3.1/ 
> fhourstones3.1                    | 0.0500 8160     0.0500       
> *                0.0500      |    1.63    1.70    1.58 *            
> 1.64 | 0.96    1.03    n/a          n/a
> MultiSource/Benchmarks/Fhourstones/ 
> fhourstones                           | 0.0699 11088    0.0600       
> *                0.0500      |    1.42    1.32    1.33 *            
> 1.39 | 1.08    1.07    n/a          n/a
> MultiSource/Benchmarks/FreeBench/analyzer/ 
> analyzer                       | 0.0600 10052    0.0600       
> *                0.0600      |    0.14    0.14    0.12 *            
> 0.18 | 1.00    1.17    n/a          n/a
> MultiSource/Benchmarks/FreeBench/distray/ 
> distray                         | 0.0200 6952     0.0300       
> *                0.0300      |    0.16    0.17    0.18 *            
> 0.23 | 0.94    0.89    n/a          n/a
> MultiSource/Benchmarks/FreeBench/fourinarow/ 
> fourinarow                   | 0.1099 18888    0.1199       
> *                0.0900      |    0.36    0.35    0.37 *            
> 0.47 | 1.03    0.97    n/a          n/a
> MultiSource/Benchmarks/FreeBench/mason/ 
> mason                             | 0.0300 6148     0.0200       
> *                0.0300      |    0.23    0.26    0.25 *            
> 0.29 | 0.88    0.92    n/a          n/a
> MultiSource/Benchmarks/FreeBench/neural/ 
> neural                           | 0.0700 9712     0.0500       
> *                0.0699      |    0.24    0.27    0.23 *            
> 0.34 | 0.89    1.04    n/a          n/a
> MultiSource/Benchmarks/FreeBench/pcompress2/ 
> pcompress2                   | 0.0599 11084    0.0500       
> *                0.0600      |    0.23    0.21    0.21 *            
> 0.29 | 1.10    1.10    n/a          n/a
> MultiSource/Benchmarks/FreeBench/pifft/ 
> pifft                             | 0.2900 60776    0.3400       
> *                0.3300      |    0.14    0.14    0.14 *            
> 0.50 | 1.00    1.00    n/a          n/a
> MultiSource/Benchmarks/MallocBench/cfrac/ 
> cfrac                           | 0.2100 92260    0.3600       
> *                0.3500      |    1.44    1.44    1.38 *            
> 1.80 | 1.00    1.04    n/a          n/a
> MultiSource/Benchmarks/MallocBench/espresso/ 
> espresso                     | 1.4700 414748   2.4299       
> *                1.6400      |    0.61    0.55    0.54 *            
> 2.27 | 1.11    1.13    n/a          n/a
> 			llc: /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
> CBackend.cpp:488:  
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
> (llvm::formatted_raw_ostream&, const llvm::Type*, bool, const  
> std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not  
> implemented yet"' failed.
> MultiSource/Benchmarks/MallocBench/gs/ 
> gs                                 | 1.2000 376224   1.7600       
> *                0.7900      |    0.07 *          0.06 *            
> 0.95 | n/a     -       n/a          n/a
> MultiSource/Benchmarks/McCat/01-qbsort/ 
> qbsort                            | 0.0099 3600     0.0200       
> *                0.0300      |    0.07    0.06    0.05 *            
> 0.10 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/03-testtrie/ 
> testtrie                        | 0.0200 3756     0.0100       
> *                0.0300      |    0.02    0.01    0.01 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/04-bisect/ 
> bisect                            | 0.0300 4036     0.0400       
> *                0.0199      |    0.14    0.13    0.13 *            
> 0.17 | 1.08    1.08    n/a          n/a
> MultiSource/Benchmarks/McCat/05-eks/ 
> eks                                  | 0.0999 7888     0.0500       
> *                0.0500      |    0.01    0.00    0.02 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/08-main/ 
> main                                | 0.0900 11928    0.0500       
> *                0.0599      |    0.07    0.03    0.03 *            
> 0.09 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/09-vor/ 
> vor                                  | 0.0999 23148    0.1300       
> *                0.1200      |    0.15    0.12    0.11 *            
> 0.25 | 1.25    1.36    n/a          n/a
> MultiSource/Benchmarks/McCat/12-IOtest/ 
> iotest                            | 0.0199 2176     0.0100       
> *                0.0200      |    0.33    0.23    0.20 *            
> 0.23 | 1.43    1.65    n/a          n/a
> MultiSource/Benchmarks/McCat/15-trie/ 
> trie                                | 0.0100 3216     0.0300       
> *                0.0300      |    0.00    0.00    0.00 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/17-bintr/ 
> bintr                              | 0.0199 3676     0.0199       
> *                0.0300      |    0.11    0.10    0.11 *            
> 0.13 | 1.10    1.00    n/a          n/a
> MultiSource/Benchmarks/McCat/18-imp/ 
> imp                                  | 0.0999 21512    0.1099       
> *                0.1200      |    0.07 *          0.08 *            
> 0.20 | n/a     -       n/a          n/a
> 			llc: /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
> CBackend.cpp:488:  
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
> (llvm::formatted_raw_ostream&, const llvm::Type*, bool, const  
> std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not  
> implemented yet"' failed.
> MultiSource/Benchmarks/MiBench/automotive-basicmath/automotive- 
> basicmath | 0.0200 4816     0.0300      *                0.0400       
> |    0.40    0.39    0.39 *           0.44 | 1.03    1.03    n/ 
> a          n/a
> MultiSource/Benchmarks/MiBench/automotive-bitcount/automotive- 
> bitcount   | 0.0300 3540     0.0200      *                 
> 0.0399      |    0.13    0.13    0.15 *           0.19 | 1.00     
> 0.87    n/a          n/a
> MultiSource/Benchmarks/MiBench/automotive-susan/automotive- 
> susan         | 0.2500 64756    0.3100      *                 
> 0.3200      |    0.07    0.06    0.05 *           0.38 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/consumer-jpeg/consumer- 
> jpeg               | 1.2500 205708   0.9300      *                 
> 0.4900      |    0.02    0.01    0.01 *           0.54 | -        
> -       n/a          n/a
> 			llc: /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
> CBackend.cpp:488:  
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
> (llvm::formatted_raw_ostream&, const llvm::Type*, bool, const  
> std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not  
> implemented yet"' failed.
> MultiSource/Benchmarks/MiBench/consumer-lame/consumer- 
> lame               | 1.3200 335108   1.3200      *                 
> 1.2100      |    0.28 *          0.27 *           1.58 | n/a      
> 1.04    n/a          n/a
> MultiSource/Benchmarks/MiBench/consumer-typeset/consumer- 
> typeset         | 5.7999 1397316  6.9899      *                 
> 6.0300      |    0.35 *          0.22 *           6.47 | n/a      
> 1.59    n/a          n/a
> MultiSource/Benchmarks/MiBench/network-dijkstra/network- 
> dijkstra         | 0.0100 3512     0.0300      *                 
> 0.0200      |    0.04    0.05    0.05 *           0.07 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/network-patricia/network- 
> patricia         | 0.0300 4248     0.0300      *                 
> 0.0200      |    0.14    0.12    0.12 *           0.16 | 1.17     
> 1.17    n/a          n/a
> MultiSource/Benchmarks/MiBench/office-ispell/office- 
> ispell               | 0.5400 128620   0.7899      *                 
> 0.2400      |    0.01    0.00    0.00 *           0.26 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/office-stringsearch/office- 
> stringsearch   | 0.0200 13232    0.0199      *                 
> 0.0300      |    0.00    0.01    0.00 *           0.03 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/security-blowfish/security- 
> blowfish       | 0.0999 30936    0.1099      *                 
> 0.0600      |    0.01    0.00    0.00 *           0.07 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/security-rijndael/security- 
> rijndael       | 0.1400 51232    0.1000      *                 
> 0.0700      |    0.08    0.06    0.07 *           0.16 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/security-sha/security- 
> sha                 | 0.0300 4760     0.0300      *                 
> 0.0300      |    0.07    0.03    0.03 *           0.05 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/telecomm-CRC32/telecomm- 
> CRC32             | 0.0000 3180     0.0100      *                 
> 0.0000      |    0.41    0.28    0.28 *           0.30 | 1.46     
> 1.46    n/a          n/a
> MultiSource/Benchmarks/MiBench/telecomm-FFT/telecomm- 
> fft                 | 0.0200 4880     0.0300      *                 
> 0.0199      |    0.06    0.07    0.06 *           0.09 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/telecomm-adpcm/telecomm- 
> adpcm             | 0.0000 2196     0.0100      *                 
> 0.0100      |    0.01    0.00    0.00 *           0.02 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm- 
> gsm                 | 0.3500 76716    0.3299      *                 
> 0.1900      |    0.23    0.24    0.23 *           0.43 | 0.96     
> 1.00    n/a          n/a
> MultiSource/Benchmarks/NPB-serial/is/ 
> is                                  | 0.0099 5116     0.0300       
> *                0.3599      |   10.08    9.85    9.84 *           
> 10.18 | 1.02    1.02    n/a          n/a
> MultiSource/Benchmarks/Olden/bh/ 
> bh                                       | 0.1199 15308     
> 0.0800      *                0.0699      |    1.97 *          1.57  
> *           1.67 | n/a     1.25    n/a          n/a
> MultiSource/Benchmarks/Olden/bisort/ 
> bisort                               | 0.0100 3688     0.0199       
> *                0.0200      |    0.80    0.82    0.79 *            
> 0.81 | 0.98    1.01    n/a          n/a
> MultiSource/Benchmarks/Olden/em3d/ 
> em3d                                   | 0.0400 6412     0.0400       
> *                0.0499      |    3.30    3.29    3.29 *            
> 3.32 | 1.00    1.00    n/a          n/a
> MultiSource/Benchmarks/Olden/health/ 
> health                               | 0.0300 7608     0.0400       
> *                0.0300      |    0.52 *          0.50 *            
> 0.54 | n/a     1.04    n/a          n/a
> MultiSource/Benchmarks/Olden/mst/ 
> mst                                     | 0.0500 4176      
> 0.0300      *                0.0300      |    0.15    0.14    0.14  
> *           0.18 | 1.07    1.07    n/a          n/a
> MultiSource/Benchmarks/Olden/perimeter/ 
> perimeter                         | 0.0000 12340    0.0799       
> *                0.0699      |    0.36    0.34    0.32 *            
> 0.38 | 1.06    1.12    n/a          n/a
> MultiSource/Benchmarks/Olden/power/ 
> power                                 | 0.0200 8564     0.0300       
> *                0.0300      |    1.56    1.55    1.52 *            
> 1.57 | 1.01    1.03    n/a          n/a
> MultiSource/Benchmarks/Olden/treeadd/ 
> treeadd                             | 0.0100 1824     0.0200       
> *                0.0200      |    0.33    0.34    0.34 *            
> 0.34 | 0.97    0.97    n/a          n/a
> MultiSource/Benchmarks/Olden/tsp/ 
> tsp                                     | 0.0300 6988      
> 0.0300      *                0.0200      |    1.15    1.13    1.14  
> *           1.16 | 1.02    1.01    n/a          n/a
> MultiSource/Benchmarks/Olden/voronoi/ 
> voronoi                             | 0.0900 13436    0.0500       
> *                0.0400      |    0.42    0.41    0.42 *            
> 0.48 | 1.02    1.00    n/a          n/a
> MultiSource/Benchmarks/OptimizerEval/optimizer- 
> eval                      | 0.0800 29224    0.1500       
> *                0.1800      |  106.85  110.58  109.30 *           
> 96.14 | 0.97    0.98    n/a          n/a
> MultiSource/Benchmarks/PAQ8p/ 
> paq8p                                       | 0.9300 198188    
> 1.0400      *                *           |    0.00 *          0.01  
> *        *       | n/a     -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/NP/ 
> np                                | 0.0000 1188     0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/city/ 
> city                            | 0.1199 23708    0.0800       
> *                0.0699      |    0.01    0.01    0.00 *            
> 0.09 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/deriv1/ 
> deriv1                        | 0.0600 12928    0.0500       
> *                0.0600      |    0.01    0.00    0.00 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/deriv2/ 
> deriv2                        | 0.0400 14480    0.0700       
> *                0.0499      |    0.00    0.00    0.00 *            
> 0.07 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/employ/ 
> employ                        | 0.1000 21900    0.1099       
> *                0.0799      |    0.02    0.01    0.01 *            
> 0.10 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/family/ 
> family                        | 0.0300 3388     0.0200       
> *                0.0199      |    0.00    0.01    0.00 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/fsm/ 
> fsm                              | 0.0100 1904     0.0100       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.02 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/garage/ 
> garage                        | 0.0499 7428     0.0400       
> *                0.0400      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/life/ 
> life                            | 0.0200 6324     0.0300       
> *                0.0100      |    1.38    1.44    1.45 *            
> 1.48 | 0.96    0.95    n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/objects/ 
> objects                      | 0.0300 9980     0.0500       
> *                0.0200      |    0.00    0.01    0.00 *            
> 0.02 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/ocean/ 
> ocean                          | 0.0200 8880     0.0500       
> *                0.0399      |    0.12    0.11    0.12 *            
> 0.16 | 1.09    1.00    n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/office/ 
> office                        | 0.0400 12924    0.0699       
> *                0.0500      |    0.00    0.00    0.00 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/primes/ 
> primes                        | 0.0100 1584     0.0100       
> *                0.0100      |    0.37    0.35    0.35 *            
> 0.37 | 1.06    1.06    n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/shapes/ 
> shapes                        | 0.0399 16268    0.0899       
> *                0.0699      |    0.01    0.01    0.01 *            
> 0.08 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/simul/ 
> simul                          | 0.0600 4176     0.0200       
> *                0.0100      |    0.01    0.01    0.01 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/trees/ 
> trees                          | 0.0500 11288    0.0700       
> *                0.0500      |    0.00    0.01    0.00 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/vcirc/ 
> vcirc                          | 0.0100 1768     0.0000       
> *                0.0000      |    0.01    0.00    0.01 *            
> 0.02 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/TimberWolfMC/ 
> timberwolfmc              | 1.7300 563480   3.2999       
> *                0.5900      |    0.01    0.00    0.00 *            
> 0.63 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/agrep/ 
> agrep                            | 0.3700 92964    0.5300       
> *                0.1999      |    0.02    0.01    0.01 *            
> 0.23 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/allroots/ 
> allroots                      | 0.0200 3556     0.0200       
> *                0.0200      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/archie-client/ 
> archie                   | 0.2000 47648    0.2199       
> *                0.0600      |    0.01 *          0.00 *            
> 0.07 | n/a     -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/assembler/ 
> assembler                    | 0.1600 61544    0.3900       
> *                0.2999      |    0.00    0.00    0.00 *            
> 0.33 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/bison/ 
> mybison                          | 0.3600 112424   0.9900       
> *                0.9100      |    0.00    0.00    0.00 *            
> 0.95 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/cdecl/ 
> cdecl                            | 0.0999 48484    0.3199       
> *                0.3400      |    0.01    0.00    0.00 *            
> 0.35 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/compiler/ 
> compiler                      | 0.1100 36440    0.2900       
> *                0.0500      |    0.00    0.00    0.00 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/fixoutput/ 
> fixoutput                    | 0.0100 6044     0.0400       
> *                0.0200      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/football/ 
> football                      | 0.3500 85712    0.5500       
> *                0.0400      |    0.00    0.00    0.01 *            
> 0.05 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/gnugo/ 
> gnugo                            | 0.1400 35692    0.2100       
> *                0.2200      |    0.07    0.07    0.07 *            
> 0.30 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/loader/ 
> loader                          | 0.0899 28276    0.1400       
> *                0.1199      |    0.00    0.00    0.00 *            
> 0.14 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/plot2fig/ 
> plot2fig                      | 0.0500 14756    0.0900       
> *                0.0999      |    0.00    0.00    0.01 *            
> 0.11 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/simulator/ 
> simulator                    | 0.2600 64712    0.4000       
> *                0.0500      |    0.00    0.01    0.00 *            
> 0.07 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/unix-smail/unix- 
> smail                  | 0.1100 39652    0.3000       
> *                0.2000      |    0.00    0.01    0.00 *            
> 0.22 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/unix-tbl/unix- 
> tbl                      | 0.3000 78708    0.4900       
> *                0.0200      |    0.00    0.00    0.01 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/Ptrdist/anagram/ 
> anagram                           | 0.0500 7764     0.0500       
> *                0.0300      |    1.46    0.97    1.38 *            
> 1.36 | 1.51    1.06    n/a          n/a
> MultiSource/Benchmarks/Ptrdist/bc/ 
> bc                                     | 0.3300 126012   0.7700       
> *                0.7100      |    0.66    0.68    0.64 *            
> 1.41 | 0.97    1.03    n/a          n/a
> MultiSource/Benchmarks/Ptrdist/ft/ 
> ft                                     | 0.0600 7236     0.0500       
> *                0.0400      |    1.17    1.22    1.27 *            
> 1.28 | 0.96    0.92    n/a          n/a
> MultiSource/Benchmarks/Ptrdist/ks/ 
> ks                                     | 0.0299 11912    0.0699       
> *                0.0700      |    2.23    1.44    2.26 *            
> 2.21 | 1.55    0.99    n/a          n/a
> MultiSource/Benchmarks/Ptrdist/yacr2/ 
> yacr2                               | 0.2200 48228    0.3600       
> *                0.3100      |    1.23    1.10    1.22 *            
> 1.56 | 1.12    1.01    n/a          n/a
> MultiSource/Benchmarks/SciMark2-C/ 
> scimark2                               | 0.1099 15340    0.0799       
> *                0.0999      |   27.62 *         27.38 *           
> 27.87 | n/a     1.01    n/a          n/a
> MultiSource/Benchmarks/Trimaran/enc-3des/ 
> enc-3des                        | 0.1599 21456    0.1000       
> *                0.1200      |    2.23    2.10    2.14 *            
> 2.31 | 1.06    1.04    n/a          n/a
> MultiSource/Benchmarks/Trimaran/enc-md5/enc- 
> md5                          | 0.0599 7692     0.0400       
> *                0.0400      |    2.16    2.04    2.05 *            
> 2.21 | 1.06    1.05    n/a          n/a
> MultiSource/Benchmarks/Trimaran/enc-pc1/enc- 
> pc1                          | 0.0300 3964     0.0199       
> *                0.0300      |    1.39    0.97    0.92 *            
> 0.95 | 1.43    1.51    n/a          n/a
> MultiSource/Benchmarks/Trimaran/enc-rc4/enc- 
> rc4                          | 0.0000 2960     0.0100       
> *                0.0100      |    1.18    1.20    1.16 *            
> 1.24 | 0.98    1.02    n/a          n/a
> MultiSource/Benchmarks/Trimaran/netbench-crc/netbench- 
> crc                | 0.0000 32680    0.0100      *                 
> 0.0100      |    1.01    1.00    1.09 *           1.07 | 1.01     
> 0.93    n/a          n/a
> MultiSource/Benchmarks/Trimaran/netbench-url/netbench- 
> url                | 0.0400 40832    0.0500      *                 
> 0.0400      |    3.89    3.45    3.88 *           3.94 | 1.13     
> 1.00    n/a          n/a
> MultiSource/Benchmarks/VersaBench/8b10b/ 
> 8b10b                            | 0.0000 2240     0.0100       
> *                0.0100      |    7.07    4.94    4.99 *            
> 4.97 | 1.43    1.42    n/a          n/a
> MultiSource/Benchmarks/VersaBench/beamformer/ 
> beamformer                  | 0.0400 5764     0.0300       
> *                0.0300      |    1.85    1.92    1.76 *            
> 1.80 | 0.96    1.05    n/a          n/a
> MultiSource/Benchmarks/VersaBench/bmm/ 
> bmm                                | 0.0199 2896     0.0100       
> *                0.0300      |    2.34    2.35    2.36 *            
> 2.39 | 1.00    0.99    n/a          n/a
> MultiSource/Benchmarks/VersaBench/dbms/ 
> dbms                              | 0.1200 36468    0.2500       
> *                0.2400      |    2.34    2.23    2.17 *            
> 2.35 | 1.05    1.08    n/a          n/a
> MultiSource/Benchmarks/VersaBench/ecbdes/ 
> ecbdes                          | 0.0599 9740     0.0200       
> *                0.0200      |    2.87    2.91    2.77 *            
> 2.76 | 0.99    1.04    n/a          n/a
> MultiSource/Benchmarks/llubenchmark/ 
> llu                                  | 0.0000 3896     0.0300       
> *                0.0300      |    6.10    6.30    6.24 *            
> 6.31 | 0.97    0.98    n/a          n/a
> MultiSource/Benchmarks/mafft/ 
> pairlocalalign                              | 3.7200 346176    
> 1.9100      *                *           |    0.00    0.00    0.00  
> *           0.00 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/adpcm/rawcaudio/ 
> rawcaudio              | 0.0100 2324     0.0100       
> *                0.0100      |    0.00    0.01    0.01 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/adpcm/rawdaudio/ 
> rawdaudio              | 0.0100 2196     0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.02 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/g721/g721encode/ 
> encode                 | 0.0600 13104    0.0800       
> *                0.0600      |    0.09    0.09    0.08 *            
> 0.14 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/gsm/toast/ 
> toast                        | 0.3800 76716    0.2700       
> *                0.2099      |    0.06    0.04    0.03 *            
> 0.24 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/ 
> cjpeg                     | 1.2000 172872   0.7500       
> *                0.5500      |    0.02    0.00    0.01 *            
> 0.61 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec/ 
> mpeg2decode             | 0.4500 101376   0.5500       
> *                0.5400      |    0.04    0.02    0.03 *            
> 0.58 | -       -       n/a          n/a
> MultiSource/Benchmarks/sim/ 
> sim                                           | 0.0699 28828     
> 0.1800      *                0.1800      |    5.21    5.51    5.24  
> *           5.82 | 0.95    0.99    n/a          n/a
> MultiSource/Benchmarks/tramp3d-v4/tramp3d- 
> v4                             | 9.2000 1943356  5.4000       
> *                5.1900      |    0.76 *          0.64 *            
> 6.36 | n/a     1.19    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> functionobjects                        | 0.2100 37048    0.1799       
> *                0.1500      |    3.97    3.53    3.43 *            
> 3.66 | 1.12    1.16    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> loop_unroll                            | 1.0500 328448   1.6400       
> *                1.7599      |    2.01    1.55    1.81 *            
> 3.63 | 1.30    1.11    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> simple_types_constant_folding          | 0.8100 185728   2.1699       
> *                2.2599      |    1.29    1.29    1.24 *            
> 3.61 | 1.00    1.04    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> simple_types_loop_invariant            | 0.6200 137560   1.1100       
> *                1.1199      |    3.01    3.02    2.97 *            
> 4.15 | 1.00    1.01    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> stepanov_abstraction                   | 0.2900 37900    0.1700       
> *                0.1599      |    5.00    5.44    5.26 *            
> 5.55 | 0.92    0.95    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> stepanov_vector                        | 0.2800 41564    0.1999       
> *                0.2100      |    2.93    3.09    2.97 *            
> 3.19 | 0.95    0.99    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> fannkuch                           | 0.0199 2840     0.0199       
> *                0.0000      |    3.45    4.30    3.49 *            
> 3.57 | 0.80    0.99    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> fasta                              | 0.0000 3000     0.0200       
> *                0.0200      |    1.17    1.19    1.16 *            
> 1.18 | 0.98    1.01    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/n- 
> body                             | 0.0000 3176     0.0200       
> *                0.0100      |    1.20    1.19    1.24 *            
> 1.23 | 1.01    0.97    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/nsieve- 
> bits                        | 0.0000 1120     0.0100       
> *                0.0100      |    0.99    1.02    1.00 *            
> 0.96 | 0.97    0.99    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> partialsums                        | 0.0000 1660     0.0000       
> *                0.0100      |    0.85    0.91    0.90 *            
> 0.83 | 0.93    0.94    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> puzzle                             | 0.0200 1276     0.0000       
> *                0.0100      |    0.54    0.54    0.54 *            
> 0.54 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> recursive                          | 0.0000 3444     0.0200       
> *                0.0200      |    1.21    0.86    0.94 *            
> 1.14 | 1.41    1.29    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/spectral- 
> norm                      | 0.0300 2808     0.0200       
> *                0.0200      |    1.37    1.41    1.41 *            
> 1.41 | 0.97    0.97    n/a          n/a
> SingleSource/Benchmarks/CoyoteBench/ 
> almabench                            | 0.0100 5776     0.0200       
> *                0.0100      |   16.77    7.95    8.05 *            
> 8.12 | 2.11    2.08    n/a          n/a
> SingleSource/Benchmarks/CoyoteBench/ 
> fftbench                             | 0.1400 22432    0.0900       
> *                0.0999      |    2.26 *          2.21 *            
> 2.35 | n/a     1.02    n/a          n/a
> SingleSource/Benchmarks/CoyoteBench/ 
> huffbench                            | 0.0300 6584     0.0300       
> *                0.0400      |   19.18   17.21   18.83 *           
> 19.82 | 1.11    1.02    n/a          n/a
> SingleSource/Benchmarks/CoyoteBench/ 
> lpbench                              | 0.0400 4556     0.0300       
> *                0.0400      |   10.94   10.91   10.95 *           
> 10.94 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Dhrystone/ 
> dry                                    | 0.0100 1300     0.0200       
> *                0.0000      |    3.29    0.35    0.62 *            
> 0.59 | 9.40    5.31    n/a          n/a
> SingleSource/Benchmarks/Dhrystone/ 
> fldry                                  | 0.0099 1308     0.0100       
> *                0.0100      |    3.66    0.46    0.58 *            
> 0.56 | 7.96    6.31    n/a          n/a
> SingleSource/Benchmarks/McGill/ 
> chomp                                     | 0.0400 6596      
> 0.0600      *                0.0500      |    1.36    1.03    1.00  
> *           1.08 | 1.32    1.36    n/a          n/a
> SingleSource/Benchmarks/McGill/ 
> exptree                                   | 0.0300 4936      
> 0.0300      *                0.0300      |    0.00    0.00    0.00  
> *           0.04 | -       -       n/a          n/a
> SingleSource/Benchmarks/McGill/ 
> misr                                      | 0.0200 2708      
> 0.0200      *                0.0200      |    0.29    0.30    0.28  
> *           0.31 | 0.97    1.04    n/a          n/a
> SingleSource/Benchmarks/McGill/ 
> queens                                    | 0.0199 3348      
> 0.0200      *                0.0199      |    2.39    2.40    2.36  
> *           2.54 | 1.00    1.01    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> bigfib                                  | 0.1900 40720     
> 0.2000      *                0.1700      |    0.56 *          0.56  
> *           0.77 | n/a     1.00    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/mandel- 
> text                             | 0.0000 1016     0.0100       
> *                0.0100      |    2.26    2.26    2.25 *            
> 2.25 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> oopack_v1p8                             | 0.0700 9528      
> 0.0400      *                0.0500      |    0.17    0.18    0.18  
> *           0.24 | 0.94    0.94    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> ray                                     | 0.0800 17220     
> 0.0700      *                0.0699      |    4.25    4.09    4.16  
> *           4.20 | 1.04    1.02    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> sphereflake                             | 0.0799 16776     
> 0.0799      *                0.0699      |    3.09    2.79    2.85  
> *           2.98 | 1.11    1.08    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> stepanov_container                      | 0.2900 46332     
> 0.1799      *                0.1899      |    4.29    4.40    4.30  
> *           4.68 | 0.97    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> stepanov_v1p2                           | 0.0800 10116     
> 0.0500      *                0.0500      |    7.87    8.27    8.11  
> *           8.24 | 0.95    0.97    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> ReedSolomon                                 | 0.0799 10636     
> 0.0600      *                0.0499      |    7.06    7.27    7.06  
> *           7.49 | 0.97    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> fbench                                      | 0.0100 5424      
> 0.0200      *                0.0400      |    2.30    2.23    2.29  
> *           2.34 | 1.03    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> ffbench                                     | 0.0200 4828      
> 0.0300      *                0.0300      |    1.04    1.00    1.04  
> *           1.08 | 1.04    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops                                       | 0.0300 6552      
> 0.0300      *                0.0300      |   12.41   12.50   12.63  
> *          12.68 | 0.99    0.98    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-1                                     | 0.0000 1152      
> 0.0100      *                0.0100      |    2.59    2.53    2.54  
> *           2.53 | 1.02    1.02    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-2                                     | 0.0000 1252      
> 0.0000      *                0.0200      |    1.46    1.46    1.46  
> *           1.49 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-3                                     | 0.0100 1172      
> 0.0100      *                0.0100      |    2.63    3.13    2.97  
> *           2.98 | 0.84    0.89    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-4                                     | 0.0000 1152      
> 0.0000      *                0.0000      |    1.23    1.37    1.34  
> *           1.36 | 0.90    0.92    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-5                                     | 0.0000 1284      
> 0.0000      *                0.0000      |    2.15    4.37    4.34  
> *           4.35 | 0.49    0.50    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-6                                     | 0.0100 1284      
> 0.0100      *                0.0100      |    2.23    4.94    4.92  
> *           4.92 | 0.45    0.45    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-7                                     | 0.0100 1080      
> 0.0000      *                0.0000      |    3.91    3.79    3.79  
> *           4.74 | 1.03    1.03    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-8                                     | 0.0000 1288      
> 0.0100      *                0.0000      |    2.23    2.43    2.29  
> *           2.30 | 0.92    0.97    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> himenobmtxpa                                | 0.0600 9672      
> 0.0500      *                0.0600      |    2.11    2.00    1.99  
> *           2.10 | 1.05    1.06    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> mandel                                      | 0.0000 1080      
> 0.0000      *                0.0100      |    1.05    1.02    1.04  
> *           1.41 | 1.03    1.01    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> mandel-2                                    | 0.0100 1052      
> 0.0000      *                0.0000      |    1.01    1.10    1.00  
> *           1.00 | 0.92    1.01    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> oourafft                                    | 0.1100 13740     
> 0.0700      *                0.0699      |    8.26    7.63    7.81  
> *           6.87 | 1.08    1.06    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> perlin                                      | 0.0200 4512      
> 0.0300      *                0.0200      |    6.64    6.67    6.65  
> *           6.89 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> pi                                          | 0.0000 1152      
> 0.0100      *                0.0000      |    0.77    0.79    0.76  
> *           0.84 | 0.97    1.01    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> richards_benchmark                          | 0.0300 5756      
> 0.0100      *                0.0300      |    1.13    1.05    1.17  
> *           1.33 | 1.08    0.97    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> salsa20                                     | 0.0100 2692      
> 0.0100      *                0.0100      |    9.30    9.72    9.27  
> *           9.33 | 0.96    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> whetstone                                   | 0.0199 3344      
> 0.0199      *                0.0199      |    1.63    1.52    1.52  
> *           1.58 | 1.07    1.07    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> ackermann                           | 0.0499 11044    0.0500       
> *                0.0400      |    1.14    1.14    1.14 *            
> 1.39 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> ary                                 | 0.0300 9120     0.0299       
> *                0.0499      |    0.12    0.11    0.11 *            
> 0.16 | 1.09    1.09    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> ary2                                | 0.0599 9784     0.0200       
> *                0.0500      |    0.12    0.12    0.12 *            
> 0.17 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> ary3                                | 0.0599 11616    0.0599       
> *                0.0599      |    4.28    4.26    4.30 *            
> 4.34 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> except                              | 0.0399 11292    0.0600       
> *                *           |    0.42 *          0.41 *         
> *       | n/a     1.02    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> fibo                                | 0.0300 7836     0.0400       
> *                0.0300      |    0.50    0.57    0.51 *            
> 0.63 | 0.88    0.98    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> hash                                | 0.0700 15036    0.0600       
> *                0.1300      |    0.60    0.58    0.59 *            
> 0.78 | 1.03    1.02    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> hash2                               | 0.1900 20104    0.1000       
> *                0.0899      |    4.53    4.35    4.33 *            
> 4.76 | 1.04    1.05    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> heapsort                            | 0.0100 3012     0.0100       
> *                0.0199      |    4.26    4.05    4.15 *            
> 4.25 | 1.05    1.03    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> hello                               | 0.0300 8304     0.0400       
> *                0.0300      |    0.01    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> lists                               | 0.0899 11392    0.0499       
> *                0.0399      |    5.90    6.00    5.86 *            
> 6.10 | 0.98    1.01    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> lists1                              | 0.1200 16204    0.0799       
> *                0.1199      |    0.33    0.34    0.33 *            
> 0.46 | 0.97    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> matrix                              | 0.0400 12192    0.0600       
> *                0.0599      |    3.33    3.34    3.35 *            
> 3.40 | 1.00    0.99    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> methcall                            | 0.0299 10800    0.0500       
> *                0.0299      |    5.47    5.57    5.59 *            
> 8.15 | 0.98    0.98    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> moments                             | 0.0599 9084     0.0400       
> *                0.0300      |    0.18    0.20    0.20 *            
> 0.22 | 0.90    0.90    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> nestedloop                          | 0.0499 8064     0.0400       
> *                0.0300      |    0.18    0.01    0.18 *            
> 0.22 | -       1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> objinst                             | 0.0400 10992    0.0500       
> *                0.0499      |    5.73    5.80    5.64 *            
> 5.66 | 0.99    1.02    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> random                              | 0.0500 7816     0.0300       
> *                0.0299      |    4.68    4.55    4.69 *            
> 4.59 | 1.03    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> reversefile                         | 0.1500 17388    0.0600       
> *                0.0600      |    0.00 *          0.00 *            
> 0.07 | n/a     -       n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> sieve                               | 0.0900 12556    0.0499       
> *                0.0499      |    2.35    2.50    2.49 *            
> 2.43 | 0.94    0.94    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> spellcheck                          | 0.1600 27772    0.1200       
> *                0.0799      |    0.01    0.00    0.00 *            
> 0.09 | -       -       n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> strcat                              | 0.0699 10564    0.0500       
> *                0.0399      |    0.15 *          0.10 *            
> 0.15 | n/a     1.50    n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> sumcol                              | 0.0499 9016     0.0400       
> *                0.0400      |    0.00    0.01    0.00 *            
> 0.04 | -       -       n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> wc                                  | 0.0599 11144    0.0400       
> *                0.0500      |    0.00    0.00    0.00 *            
> 0.05 | -       -       n/a          n/a
> SingleSource/Benchmarks/Shootout-C++/ 
> wordfreq                            | 0.1000 18728    0.0900       
> *                0.0500      |    0.00    0.00    0.01 *            
> 0.07 | -       -       n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> ackermann                               | 0.0100 1192      
> 0.0100      *                0.0100      |    0.02    0.01    0.01  
> *           0.02 | -       -       n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> ary3                                    | 0.0000 1148      
> 0.0000      *                0.0000      |    4.40    4.32    4.48  
> *           4.33 | 1.02    0.98    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> fib2                                    | 0.0000 964       
> 0.0200      *                0.0100      |    0.50    0.58    0.51  
> *           0.60 | 0.86    0.98    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> hash                                    | 0.0300 3028      
> 0.0100      *                0.0100      |    3.79    3.80    3.83  
> *           4.08 | 1.00    0.99    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> heapsort                                | 0.0000 1452      
> 0.0100      *                0.0000      |    4.10    4.09    4.13  
> *           4.32 | 1.00    0.99    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> hello                                   | 0.0000 576       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> lists                                   | 0.0300 3144      
> 0.0200      *                0.0100      |    5.85    5.77    5.75  
> *           6.34 | 1.01    1.02    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> matrix                                  | 0.0099 4128      
> 0.0200      *                0.0100      |    3.88    3.88    3.87  
> *           3.90 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> methcall                                | 0.0000 1580      
> 0.0100      *                0.0099      |    4.52    4.41    4.51  
> *           7.02 | 1.02    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> nestedloop                              | 0.0200 1128      
> 0.0100      *                0.0100      |    0.18    0.02    0.17  
> *           0.25 | -       1.06    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> objinst                                 | 0.0100 1676      
> 0.0100      *                0.0000      |    5.01    5.50    5.17  
> *           5.06 | 0.91    0.97    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> random                                  | 0.0000 864       
> 0.0000      *                0.0100      |    4.55    4.52    4.53  
> *           4.54 | 1.01    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> sieve                                   | 0.0000 1288      
> 0.0000      *                0.0100      |    6.56    5.95    6.55  
> *           6.46 | 1.10    1.00    n/a          n/a
> SingleSource/Benchmarks/Shootout/ 
> strcat                                  | 0.0000 1336      
> 0.0100      *                0.0200      |    0.20    0.19    0.20  
> *           0.22 | 1.05    1.00    n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> Bubblesort                              | 0.0100 1420      
> 0.0100      *                0.0100      |    0.05    0.06    0.07  
> *           0.07 | -       -       n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> IntMM                                   | 0.0200 1476      
> 0.0100      *                0.0100      |    0.01    0.00    0.00  
> *           0.02 | -       -       n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> Oscar                                   | 0.0300 3148      
> 0.0200      *                0.0100      |    0.01    0.00    0.00  
> *           0.02 | -       -       n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> Perm                                    | 0.0000 3124      
> 0.0200      *                0.0200      |    0.04    0.04    0.04  
> *           0.07 | -       -       n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> Puzzle                                  | 0.0999 4820      
> 0.0199      *                0.0300      |    0.17    0.19    0.18  
> *           0.20 | 0.89    0.94    n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> Queens                                  | 0.0200 2232      
> 0.0100      *                0.0199      |    0.05    0.05    0.04  
> *           0.07 | -       -       n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> Quicksort                               | 0.0100 1752      
> 0.0100      *                0.0200      |    0.05    0.05    0.06  
> *           0.07 | -       -       n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> RealMM                                  | 0.0100 1508      
> 0.0100      *                0.0100      |    0.00    0.00    0.01  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> Towers                                  | 0.0200 2440      
> 0.0200      *                0.0200      |    0.04    0.04    0.03  
> *           0.05 | -       -       n/a          n/a
> SingleSource/Benchmarks/Stanford/ 
> Treesort                                | 0.0100 2248      
> 0.0200      *                0.0200      |    0.10    0.10    0.08  
> *           0.11 | 1.00    -       n/a          n/a
> SingleSource/Regression/C++/2003-05-14-array- 
> init                        | 0.0000 584      0.0000       
> *                0.0000      |    0.00    0.00    0.01 *            
> 0.02 | -       -       n/a          n/a
> SingleSource/Regression/C++/2003-05-14- 
> expr_stmt                         | 0.0000 484      0.0000       
> *                0.0100      |    0.01    0.01    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C++/2003-06-08- 
> BaseType                          | 0.0000 496      0.0000       
> *                0.0000      |    0.00    0.01    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/Regression/C++/2003-06-08- 
> VirtualFunctions                  | 0.0000 620      0.0000       
> *                0.0000      |    0.00    0.00    0.01 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/Regression/C++/2003-06-13- 
> Crasher                           | 0.0000 456      0.0100       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C++/2003-08-20- 
> EnumSizeProblem                   | 0.0000 456      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C++/2003-09-29- 
> NonPODsByValue                    | 0.0000 576      0.0000       
> *                0.0100      |    0.00    0.01    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C++/2008-01-29- 
> ParamAliasesReturn                | 0.0200 604      0.0000       
> *                0.0000      |    0.00    0.01    0.00 *            
> 0.02 | -       -       n/a          n/a
> SingleSource/Regression/C++/ 
> BuiltinTypeInfo                              | 0.0000 728       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> ConditionalExpr                           | 0.0099 712       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.00 | -       -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> ctor_dtor_count                           | 0.0000 1056      
> 0.0000      *                *           |    0.00 *          0.00  
> *        *       | n/a     -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> ctor_dtor_count-2                         | 0.0000 1584      
> 0.0000      *                *           |    0.00 *          0.00  
> *        *       | n/a     -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> dead_try_block                            | 0.0000 568       
> 0.0000      *                0.0000      |    0.01    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> exception_spec_test                       | 0.0200 2472      
> 0.0100      *                *           |    0.00 *          0.01  
> *        *       | n/a     -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> function_try_block                        | 0.0100 2460      
> 0.0100      *                *           |    0.00 *          0.00  
> *        *       | n/a     -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> simple_rethrow                            | 0.0100 1452      
> 0.0100      *                *           |    0.01 *          0.00  
> *        *       | n/a     -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> simple_throw                              | 0.0000 956       
> 0.0000      *                *           |    0.00 *          0.01  
> *        *       | n/a     -       n/a          n/a
> SingleSource/Regression/C++/EH/ 
> throw_rethrow_test                        | 0.0000 1792      
> 0.0100      *                *           |    0.00 *          0.00  
> *        *       | n/a     -       n/a          n/a
> SingleSource/Regression/C++/ 
> global_ctor                                  | 0.0000 1344      
> 0.0100      *                0.0000      |    0.00    0.00    0.01  
> *           0.02 | -       -       n/a          n/a
> SingleSource/Regression/C++/ 
> global_type                                  | 0.0000 456       
> 0.0000      *                0.0000      |    0.00    0.00    0.01  
> *           0.00 | -       -       n/a          n/a
> SingleSource/Regression/C++/ 
> ofstream_ctor                                | 0.0400 9176      
> 0.0300      *                0.0300      |    0.00    0.01    0.00  
> *           0.04 | -       -       n/a          n/a
> SingleSource/Regression/C++/ 
> pointer_member                               | 0.0000 660       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.00 | -       -       n/a          n/a
> SingleSource/Regression/C++/ 
> pointer_method                               | 0.0000 664       
> 0.0000      *                0.0100      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C++/ 
> short_circuit_dtor                           | 0.0100 644       
> 0.0100      *                0.0000      |    0.00    0.00    0.00  
> *           0.00 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-05-14-initialize- 
> string                   | 0.0000 680      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.02 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-05-21- 
> BitfieldHandling                    | 0.0100 1152     0.0000       
> *                0.0000      |    0.00 *          0.00 *            
> 0.00 | n/a     -       n/a          n/a
> SingleSource/Regression/C/2003-05-21- 
> UnionBitfields                      | 0.0000 580      0.0000       
> *                0.0000      |    0.01    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-05-21- 
> UnionTest                           | 0.0000 580      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-05-22- 
> LocalTypeTest                       | 0.0000 624      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-05-22- 
> VarSizeArray                        | 0.0000 580      0.0100       
> *                0.0000      |    0.01    0.00    0.01 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-05-23- 
> TransparentUnion                    | 0.0000 576      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-06-16- 
> InvalidInitializer                  | 0.0000 456      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-06-16- 
> VolatileError                       | 0.0000 456      0.0100       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/Regression/C/2003-10-12- 
> GlobalVarInitializers               | 0.0000 664      0.0000       
> *                0.0000      |    0.00    0.01    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/Regression/C/2004-02-03- 
> AggregateCopy                       | 0.0000 588      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/Regression/C/2004-03-15- 
> IndirectGoto                        | 0.0000 860      0.0100       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/Regression/C/2004-08-12- 
> InlinerAndAllocas                   | 0.0000 828      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/2005-05-06- 
> LongLongSignedShift                 | 0.0000 608      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/2008-01-07- 
> LongDouble                          | 0.0000 596      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> ConstructorDestructorAttributes                | 0.0000 760       
> 0.0000      *                0.0000      |    0.00    0.01    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> DuffsDevice                                    | 0.0000 1084      
> 0.0000      *                0.0100      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> PR1386                                         | 0.0000 588       
> 0.0000      *                0.0100      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> PR491                                          | 0.0100 456       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> PR640                                          | 0.0100 2076      
> 0.0100      *                0.0100      |    0.01    0.00    0.00  
> *           0.02 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> badidx                                         | 0.0100 1012      
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> bigstack                                       | 0.0000 4820      
> 0.0200      *                0.0100      |    0.00    0.00    0.00  
> *           0.03 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> callargs                                       | 0.0000 928       
> 0.0100      *                0.0100      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> casts                                          | 0.0000 3612      
> 0.0100      *                0.0100      |    0.00    0.00    0.00  
> *           0.03 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> globalrefs                                     | 0.0000 932       
> 0.0000      *                0.0000      |    0.01    0.00    0.01  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> matrixTranspose                                | 0.0100 1364      
> 0.0100      *                0.0100      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> pointer_arithmetic                             | 0.0100 488       
> 0.0000      *                0.0100      |    0.00    0.01    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> sumarray                                       | 0.0100 948       
> 0.0100      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> sumarray2d                                     | 0.0100 1108      
> 0.0100      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> sumarraymalloc                                 | 0.0000 1184      
> 0.0000      *                0.0100      |    0.00    0.01    0.00  
> *           0.02 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> test_indvars                                   | 0.0000 1436      
> 0.0000      *                0.0100      |    0.00    0.00    0.00  
> *           0.02 | -       -       n/a          n/a
> SingleSource/Regression/C/ 
> testtrace                                      | 0.0100 1128      
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-04-17- 
> PrintfChar                             | 0.0100 576      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-05-02- 
> ArgumentTest                           | 0.0000 624      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-05-02- 
> CastTest                               | 0.0000 1508     0.0000       
> *                0.0000      |    0.00    0.00    0.01 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-05-02- 
> CastTest1                              | 0.0100 608      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-05-02- 
> CastTest2                              | 0.0000 736      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-05-02- 
> CastTest3                              | 0.0000 684      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-05-02- 
> ManyArguments                          | 0.0000 696      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-05-03- 
> NotTest                                | 0.0000 664      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-05-19- 
> DivTest                                | 0.0100 688      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-08-02- 
> CastTest                               | 0.0000 584      0.0000       
> *                0.0000      |    0.01    0.00    0.01 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-08-02- 
> CastTest2                              | 0.0000 608      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-08-19- 
> CodegenBug                             | 0.0100 568      0.0000       
> *                0.0000      |    0.00    0.00    0.01 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-10-09- 
> ArrayResolution                        | 0.0000 644      0.0100       
> *                0.0000      |    0.01    0.00    0.01 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-10-12- 
> StructureArgs                          | 0.0000 636      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-10-12- 
> StructureArgsSimple                    | 0.0000 604      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-10-13- 
> BadLoad                                | 0.0000 572      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2002-12-13- 
> MishaTest                              | 0.0000 584      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-04-22- 
> Switch                                 | 0.0000 736      0.0100       
> *                0.0000      |    0.01    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-05-02- 
> DependentPHI                           | 0.0000 816      0.0100       
> *                0.0000      |    0.01    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-05-07- 
> VarArgs                                | 0.0000 2828     0.0100       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.02 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-05-12- 
> MinIntProblem                          | 0.0000 568      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-05-14- 
> AtExit                                 | 0.0000 688      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-05-26- 
> Shorts                                 | 0.0000 2012     0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-05-31- 
> CastToBool                             | 0.0100 916      0.0100       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-05-31- 
> LongShifts                             | 0.0000 952      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-07-06- 
> IntOverflow                            | 0.0200 812      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-07-08- 
> BitOpsTest                             | 0.0000 592      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-07-09- 
> LoadShorts                             | 0.0100 1520     0.0000       
> *                0.0100      |    0.00    0.01    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-07-09- 
> SignedArgs                             | 0.0200 1676     0.0100       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-07-10- 
> SignConversions                        | 0.0000 792      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-08-05- 
> CastFPToUint                           | 0.0000 720      0.0000       
> *                0.0000      |    0.00    0.01    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-08-11- 
> VaListArg                              | 0.0100 3108     0.0100       
> *                0.0300      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-08-20- 
> FoldBug                                | 0.0000 568      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-09-18- 
> BitFieldTest                           | 0.0000 612      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-10-13- 
> SwitchTest                             | 0.0000 652      0.0000       
> *                0.0000      |    0.00    0.01    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2003-10-29- 
> ScalarReplBug                          | 0.0000 580      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2004-02-02- 
> NegativeZero                           | 0.0000 640      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2004-06-20- 
> StaticBitfieldInit                     | 0.0000 684      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2004-11-28- 
> GlobalBoolLayout                       | 0.0000 880      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2005-05-11-Popcount-ffs- 
> fls                       | 0.0100 2144     0.0200       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2005-05-12- 
> Int64ToFP                              | 0.0000 684      0.0100       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2005-05-13- 
> SDivTwo                                | 0.0000 648      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2005-07-15-Bitfield- 
> ABI                           | 0.0000 596      0.0000       
> *                0.0000      |    0.01    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2005-07-17-INT-To- 
> FP                              | 0.0100 928      0.0000       
> *                0.0000      |    0.01    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2005-11-29- 
> LongSwitch                             | 0.0100 584      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2006-01-23- 
> UnionInit                              | 0.0000 2152     0.0100       
> *                0.0100      |    0.00 *          0.00 *            
> 0.01 | n/a     -       n/a          n/a
> SingleSource/UnitTests/2006-01-29- 
> SimpleIndirectCall                     | 0.0000 796      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2006-02-04- 
> DivRem                                 | 0.0100 672      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2006-12-01- 
> float_varg                             | 0.0000 660      0.0000       
> *                0.0000      |    0.01    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2006-12-04- 
> DynAllocAndRestore                     | 0.0100 480      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2006-12-07- 
> Compare64BitConstant                   | 0.0000 592      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2006-12-11- 
> LoadConstants                          | 0.0400 2704     0.0300       
> *                0.0400      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> SingleSource/UnitTests/2007-01-04-KNR- 
> Args                               | 0.0000 668      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2007-03-02- 
> VaCopy                                 | 0.0100 944      0.0100       
> *                0.0000      |    0.01    0.00    0.01 *            
> 0.02 | -       -       n/a          n/a
> SingleSource/UnitTests/2007-04-10- 
> BitfieldTest                           | 0.0100 604      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2007-04-25- 
> weak                                   | 0.0000 512      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2008-04-18- 
> LoopBug                                | 0.0100 1052     0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2008-04-20- 
> LoopBug2                               | 0.0000 1068     0.0100       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/2008-07-13- 
> InlineSetjmp                           | 0.0000 836      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/2009-04-16- 
> BitfieldInitialization                 | 0.0100 1900     0.0000       
> *                0.0000      |    0.00 *          0.00 *            
> 0.01 | n/a     -       n/a          n/a
> SingleSource/UnitTests/ 
> AtomicOps                                         | 0.0000 812       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/ 
> FloatPrecision                                    | 0.0000 616       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/SignlessTypes/ 
> cast                                | 0.0200 2548     0.0200       
> *                0.0300      |    0.03    0.02    0.02 *            
> 0.06 | -       -       n/a          n/a
> SingleSource/UnitTests/SignlessTypes/cast- 
> bug                            | 0.0000 632      0.0000       
> *                0.0000      |    0.01    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/SignlessTypes/ 
> cast2                               | 0.0000 592      0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/SignlessTypes/ 
> ccc                                 | 0.0100 772      0.0100       
> *                0.0000      |    0.00    0.00    0.01 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/SignlessTypes/ 
> div                                 | 0.0000 1340     0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.02 | -       -       n/a          n/a
> SingleSource/UnitTests/SignlessTypes/ 
> factor                              | 0.0000 1008     0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.02 | -       -       n/a          n/a
> SingleSource/UnitTests/SignlessTypes/ 
> rem                                 | 0.0400 9136     0.1100       
> *                0.1200      |    0.01    0.00    0.00 *            
> 0.14 | -       -       n/a          n/a
> SingleSource/UnitTests/SignlessTypes/ 
> shr                                 | 0.0199 1448     0.0000       
> *                0.0000      |    0.01    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/ 
> StructModifyTest                                  | 0.0000 688       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/ 
> TestLoop                                          | 0.0000 680       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/Threads/ 
> tls                                       | 0.0000 876       
> 0.0000      *                *           |    0.00    0.01    0.00  
> *        *       | -       -       n/a          n/a
> SingleSource/UnitTests/Vector/SSE/ 
> sse.expandfft                          | 0.0100 6440     0.0300       
> *                0.0300      |    0.61    0.58    0.54 *            
> 0.60 | 1.05    1.13    n/a          n/a
> SingleSource/UnitTests/Vector/SSE/ 
> sse.isamax                             | 0.0300 3148     0.0200       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/Vector/SSE/ 
> sse.shift                              | 0.0099 828      0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/Vector/SSE/ 
> sse.stepfft                            | 0.0500 10044    0.0400       
> *                0.0600      |    0.63    0.62    0.61 *            
> 0.64 | 1.02    1.03    n/a          n/a
> SingleSource/UnitTests/Vector/ 
> build                                      | 0.0000 828       
> 0.0100      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/Vector/ 
> build2                                     | 0.0200 1152      
> 0.0000      *                0.0100      |    1.95    1.96    1.95  
> *           1.93 | 0.99    1.00    n/a          n/a
> SingleSource/UnitTests/Vector/ 
> divides                                    | 0.0100 656       
> 0.0000      *                0.0100      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/Vector/ 
> multiplies                                 | 0.0100 1744      
> 0.0200      *                0.0100      |    2.80    2.81    1.84  
> *           1.85 | 1.00    1.52    n/a          n/a
> SingleSource/UnitTests/Vector/ 
> simple                                     | 0.0100 1216      
> 0.0100      *                0.0100      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a
> SingleSource/UnitTests/Vector/ 
> sumarray                                   | 0.0100 920       
> 0.0000      *                0.0000      |    0.00    0.00    0.00  
> *           0.00 | -       -       n/a          n/a
> SingleSource/UnitTests/Vector/sumarray- 
> dbl                               | 0.0000 976      0.0100       
> *                0.0100      |    0.00    0.01    0.00 *            
> 0.02 | -       -       n/a          n/a
> SingleSource/UnitTests/ 
> printargs                                         | 0.0000 760       
> 0.0100      *                0.0000      |    0.00    0.00    0.00  
> *           0.01 | -       -       n/a          n/a


From baldrick at free.fr  Tue Oct 20 14:35:41 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 21:35:41 +0200
Subject: [cfe-dev] [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <81F09A6F-7488-4845-9D02-12DA0211D5CF@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<4ADDB4D4.5010504@free.fr>
	<81F09A6F-7488-4845-9D02-12DA0211D5CF@apple.com>
Message-ID: <4ADE110D.5050707@free.fr>

Hi Tanya,

>> Error opening 'llvm-2.6-objects/Release/lib/LLVMHello.so': 
>> llvm-2.6-objects/Release/lib/LLVMHello.so: undefined symbol: 
>> _ZN4llvm4cerrE
>> child process exited abnormally
>>
> 
> Did you compile llvm with llvm-gcc? This is exactly PR4849.

I didn't think I had, but it seems I did: I rebuilt being careful to use
gcc-4.4 and this failure went away.

>> XPASS: 
>> llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c
>>
> 
> Does using the llvm-gcc binary for x86_64 produce the same results for 
> this test?

I was unable to check because the binary links with libffi but I don't
have libffi.  I tried installing libffi but my distribution doesn't come
with the same version as llvm-gcc requires.

>>> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>>
>> Attached.
>>
> 
> This seemed to be inlined into the mail instead of attached. Can you 
> send again?

According to my outbox it was attached.  Here it is again (attached).

Ciao,

Duncan.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.nightly.txt
Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/4ddab0e5/attachment-0001.txt 

From snaroff at apple.com  Tue Oct 20 14:43:04 2009
From: snaroff at apple.com (steve naroff)
Date: Tue, 20 Oct 2009 15:43:04 -0400
Subject: [cfe-dev] Selector::getAsString problem in CIndex
In-Reply-To: <aad8390910201215o25e0b979jc361501adab1b416@mail.gmail.com>
References: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>
	<aad8390910200803v2d598a97y6fad4fccf592e198@mail.gmail.com>
	<AC3E6E17-6F34-453D-9661-74FE887829A3@apple.com>
	<aad8390910201215o25e0b979jc361501adab1b416@mail.gmail.com>
Message-ID: <5C277B15-06F0-4B73-86A1-475F5047C35D@apple.com>

Hi John,

The patch didn't apply for me (it's based on yesterday's source).  
Could you update it?

On the string lifetime issue...after consulting with Daniel, we'd  
prefer to avoid cluttering up the API to deal with lazily computed  
names (that aren't part of the AST per se).

One spin on your change...

+// For temporary string returns.
+static char CIBuffer[256];
+

...is to have a static llvm::StringSet that contains copies of the  
strings. For example:

static llvm::StringSet<> LazilyComputedShortLivedNames;

While this is more general than your change (no limit, can hold an  
arbitrary # of strings), it is static data (which is less than great).

It would be nice if this data were cached per-Index. Unfortunately,  
this would require either (a) more bookkeeping or (b) more explicit  
'CXIndex' arguments be passed around.

So...it seem like the choices are:

(a) static StringSet<> to keep the API simple (i.e. no requirement on  
the client to size/deal with strings).
(b) per-index StringSet<> to keep the string API simple. Modify the  
API to pass CXIndex in more places.
(c) per-index StringSet<> to keep the string API simple. Add  
bookkeeping to navigate from a CXDecl->CXTranslationUnit->CXIndex.
(d) Avoid passing back C strings entirely (what I previously said we'd  
like to avoid). Complicates the API, but makes the contract very  
explicit.
(e) Go with your change (documenting the limitations).

At the moment, this is primarily a problem with ObjC names (i.e.  
Selectors), however this will be an issues for C++ as well I believe  
(for names that contain type info).

As a result, I want to get other opinions on this before we make a  
decision.

Thanks much,

snaroff

On Oct 20, 2009, at 3:15 PM, John Thompson wrote:

> Here it is separated into two patches.  cindex_imports has the DLL  
> stuff plus the basename fix.  cindex_string has the string fixes  
> plus the function move.  cindex_string depends on cindex_imports.   
> (The only overlapping part is the CIndex.cpp _CINDEX_CPP_ definition  
> in cindex_imports.)
>
> Looking at _splitpath, it seems that my basename is more convenient  
> to use, since _splitpath breaks the path up into separate drive,  
> dir, fname, and ext strings, which need separate buffers.  I'd also  
> be concerned as to whether it will work with unix-style '/'  
> directory separators, whereas mine works with both.
> -John
> On Tue, Oct 20, 2009 at 8:36 AM, steve naroff <snaroff at apple.com>  
> wrote:
> Hi John,
>
> Comments below...
>
> On Oct 20, 2009, at 11:03 AM, John Thompson wrote:
>
>> Now that I have electricity again...
>>
>> Sorry, I was looking too deep, not noticing that the function  
>> returned a std::string.  The problem was up higher in CIndex.cpp,  
>> in a couple of the functions that return const char *, with the  
>> same problem I described of the temporary going away before the  
>> string can be used.
>>
>
> Nice catch. I guess other platforms are more forgiving...
>
>> I worked around it by using a static buffer, which is admittedly  
>> not so good.  A cleaner way might be to have the user pass in a  
>> string buffer, since it seems this needs to be a C interface.   
>> Should I do that, or does the API need to remain unchanged?  Let me  
>> know if there's a better way.
>>
>
> I'd like to avoid cluttering the interface if possible. I'm not an  
> expert on std::String, so I'll have to look into this. I'll get back  
> to you...
>
>> The enclosed patch contains my hacked version, which also includes  
>> the DLL exporting glue (redone in the naming style I'm used to -  
>> apologies to Jeff Krall, who'd already done it).
>>
>
> Can you separate this from the other stuff in the patch? I'd like to  
> keep this type of mechanical change separate from the trickier  
> stuff...
>
>> Note that I moved the getLocationFromCursor function out of the  
>> extern "C" {} because MSVC was complaining about it because of the  
>> object return type.
>>
>> Where does "basename" come from on the non-Windows platforms?  It  
>> was unresolved, so I guessed at it, but which seems to work.
>>
>
> basename is a Unix/Linux function...not standard C or POSIX. Does  
> Windows have something called _splitpath()?
>
>> The c-index-api-test.m test passes on Windows with these changes.
>
> Great. Thanks for helping out on this!
>
> snaroff
>
>>
>> -John
>> On Mon, Oct 19, 2009 at 12:14 PM, John Thompson <john.thompson.jtsoftware at gmail.com 
>> > wrote:
>> I'm looking at a test failure of c-index-api-test.m on Windows, and  
>> I've run into a problem I don't know how to easily fix.
>>
>> In the function Selector::getAsString function in  
>> IdentifierTable.cpp at line 330:
>>
>>     return II->getName().str() + ":";
>>
>> On Windows, at least, this isn't working as expected.  I think it's  
>> because a tempory string created gets destructed before the return  
>> completes, causing the resulting string pointer to point to  
>> garbage, resulting in garbage for the identifier name in the index  
>> output.
>>
>> If someone more knowlegeable about it could take a look at it, I'd  
>> appreciate it.
>>
>> Note that if you need to run it on windows, you'll need some CIndex  
>> changes I'm working on, but haven't completed yet, so let me know  
>> if you need them.
>>
>> -John
>>
>> -- 
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>>
>>
>>
>> -- 
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>> <cindex.patch>_______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> <cindex_string.patch><cindex_imports.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/bbd85c17/attachment.html 

From Ken.Dyck at onsemi.com  Tue Oct 20 11:22:52 2009
From: Ken.Dyck at onsemi.com (Ken Dyck)
Date: Tue, 20 Oct 2009 09:22:52 -0700
Subject: [cfe-dev] patch for generalizing stdint for n-bit bytes
In-Reply-To: <6a8523d60910191448i3cbe3eam928a2fd8ee32d98f@mail.gmail.com>
References: <BB76172E-1804-45DC-AB55-18EAB0F0F41F@gmail.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B27747844567@NAMAIL.ad.onsemi.com>
	<6a8523d60910191448i3cbe3eam928a2fd8ee32d98f@mail.gmail.com>
Message-ID: <8F2E4A8BCDA0B84DA6C9088EB5B277478448A6@NAMAIL.ad.onsemi.com>

 
On Monday, October 19, 2009 5:48 PM, Daniel wrote:
> On Mon, Oct 19, 2009 at 11:30 AM, Ken Dyck 
> <Ken.Dyck at onsemi.com> wrote:
> > On Saturday, October 17, 2009 8:17 PM, Ray wrote:
> >> This patch generalizes some of the defines produced by the 
> >> preprocessor in preparation for future patches to support of n-bit 
> >> bytes.
> >
> > Specifically, it adds support to stdint.h for all 
> mutiple-of-8 integer 
> > widths up to 64 bits, where it previously only supported 
> 8-, 16-, 32- 
> > and 64-bit widths.
> >
> >> Some other highlights include the addition of 40 new test 
> cases that 
> >> help better validate the preprocessor and target defines. ?It also 
> >> gets rid of std::vector<char> in favor of 
> llvm::raw_ostream to create 
> >> defines.
> >
> > If it helps, I'd be happy to separate the new test cases and the 
> > raw_ostream conversion into separate patches.
> 
> Yes, that would probably be very helpful!

Attached are patches for the stdint.h/InitPreprocessor.cpp modifications and some new tests that exercise preprocessor initialization. 

I'll hold off on submitting a patch for the vector<char>-to-raw_ostream conversion in InitPreprocessor.cpp until the stdint.h patch is accepted/rejected, as there is too much overlap between the two to make separating them worthwhile. 

-Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpp-init-tests.r84633.patch
Type: application/octet-stream
Size: 97543 bytes
Desc: cpp-init-tests.r84633.patch
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/21a4e79a/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stdint-generalize.r84633.patch
Type: application/octet-stream
Size: 35780 bytes
Desc: stdint-generalize.r84633.patch
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/21a4e79a/attachment-0003.obj 

From duncan.sands at math.u-psud.fr  Tue Oct 20 11:36:55 2009
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 18:36:55 +0200
Subject: [cfe-dev] [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <4ADDE727.4080202@math.u-psud.fr>

Hi Tanya, here's another one, 32 bit this time.  I forgot to mention
that the system compiler is gcc-4.4.

> 1) Compile llvm from source and untar the llvm-test in the projects 
> directory (name it llvm-test or test-suite). Choose to use a 
> pre-compiled llvm-gcc or re-compile it yourself.

I compiled llvm and llvm-gcc with separate objects directories.
Platform is i486-linux-gnu.

> 2) Run make check, report any failures (FAIL or unexpected pass). Note 
> that you need to reconfigure llvm with llvm-gcc in your path or with 
> --with-llvmgccdir

One unexpected pass:
XPASS: 
llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c

> 3) Run "make TEST=nightly report" and send me the report.nightly.txt

Attached.

Ciao,

Duncan.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.nightly.txt
Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/bc0aeda1/attachment-0001.txt 

From snaroff at apple.com  Tue Oct 20 15:03:39 2009
From: snaroff at apple.com (steve naroff)
Date: Tue, 20 Oct 2009 16:03:39 -0400
Subject: [cfe-dev] Selector::getAsString problem in CIndex
In-Reply-To: <5C277B15-06F0-4B73-86A1-475F5047C35D@apple.com>
References: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>
	<aad8390910200803v2d598a97y6fad4fccf592e198@mail.gmail.com>
	<AC3E6E17-6F34-453D-9661-74FE887829A3@apple.com>
	<aad8390910201215o25e0b979jc361501adab1b416@mail.gmail.com>
	<5C277B15-06F0-4B73-86A1-475F5047C35D@apple.com>
Message-ID: <231A885C-D42A-4A9C-9880-9D02C33E23F1@apple.com>

Just after sending this, I realized there may be another AST-based  
solution:

The ObjC AST's could implement the following:

const char *getSelectorAsCString(); // for multi-keyword selectors,  
the result would be computed/cached.

This would make the semantics uniform with getNameAsCString(). Since  
it looks like this API may be deprecated, maybe not a great idea.

Since this is only an issue when integrating a C-based API with C++,  
it may be overkill to solve this issue at the AST level...

Nevertheless, I wanted to mention it for completeness...

snaroff

On Oct 20, 2009, at 3:43 PM, steve naroff wrote:

> Hi John,
>
> The patch didn't apply for me (it's based on yesterday's source).  
> Could you update it?
>
> On the string lifetime issue...after consulting with Daniel, we'd  
> prefer to avoid cluttering up the API to deal with lazily computed  
> names (that aren't part of the AST per se).
>
> One spin on your change...
>
> +// For temporary string returns.
> +static char CIBuffer[256];
> +
>
> ...is to have a static llvm::StringSet that contains copies of the  
> strings. For example:
>
> static llvm::StringSet<> LazilyComputedShortLivedNames;
>
> While this is more general than your change (no limit, can hold an  
> arbitrary # of strings), it is static data (which is less than great).
>
> It would be nice if this data were cached per-Index. Unfortunately,  
> this would require either (a) more bookkeeping or (b) more explicit  
> 'CXIndex' arguments be passed around.
>
> So...it seem like the choices are:
>
> (a) static StringSet<> to keep the API simple (i.e. no requirement  
> on the client to size/deal with strings).
> (b) per-index StringSet<> to keep the string API simple. Modify the  
> API to pass CXIndex in more places.
> (c) per-index StringSet<> to keep the string API simple. Add  
> bookkeeping to navigate from a CXDecl->CXTranslationUnit->CXIndex.
> (d) Avoid passing back C strings entirely (what I previously said  
> we'd like to avoid). Complicates the API, but makes the contract  
> very explicit.
> (e) Go with your change (documenting the limitations).
>
> At the moment, this is primarily a problem with ObjC names (i.e.  
> Selectors), however this will be an issues for C++ as well I believe  
> (for names that contain type info).
>
> As a result, I want to get other opinions on this before we make a  
> decision.
>
> Thanks much,
>
> snaroff
>
> On Oct 20, 2009, at 3:15 PM, John Thompson wrote:
>
>> Here it is separated into two patches.  cindex_imports has the DLL  
>> stuff plus the basename fix.  cindex_string has the string fixes  
>> plus the function move.  cindex_string depends on cindex_imports.   
>> (The only overlapping part is the CIndex.cpp _CINDEX_CPP_  
>> definition in cindex_imports.)
>>
>> Looking at _splitpath, it seems that my basename is more convenient  
>> to use, since _splitpath breaks the path up into separate drive,  
>> dir, fname, and ext strings, which need separate buffers.  I'd also  
>> be concerned as to whether it will work with unix-style '/'  
>> directory separators, whereas mine works with both.
>> -John
>> On Tue, Oct 20, 2009 at 8:36 AM, steve naroff <snaroff at apple.com>  
>> wrote:
>> Hi John,
>>
>> Comments below...
>>
>> On Oct 20, 2009, at 11:03 AM, John Thompson wrote:
>>
>>> Now that I have electricity again...
>>>
>>> Sorry, I was looking too deep, not noticing that the function  
>>> returned a std::string.  The problem was up higher in CIndex.cpp,  
>>> in a couple of the functions that return const char *, with the  
>>> same problem I described of the temporary going away before the  
>>> string can be used.
>>>
>>
>> Nice catch. I guess other platforms are more forgiving...
>>
>>> I worked around it by using a static buffer, which is admittedly  
>>> not so good.  A cleaner way might be to have the user pass in a  
>>> string buffer, since it seems this needs to be a C interface.   
>>> Should I do that, or does the API need to remain unchanged?  Let  
>>> me know if there's a better way.
>>>
>>
>> I'd like to avoid cluttering the interface if possible. I'm not an  
>> expert on std::String, so I'll have to look into this. I'll get  
>> back to you...
>>
>>> The enclosed patch contains my hacked version, which also includes  
>>> the DLL exporting glue (redone in the naming style I'm used to -  
>>> apologies to Jeff Krall, who'd already done it).
>>>
>>
>> Can you separate this from the other stuff in the patch? I'd like  
>> to keep this type of mechanical change separate from the trickier  
>> stuff...
>>
>>> Note that I moved the getLocationFromCursor function out of the  
>>> extern "C" {} because MSVC was complaining about it because of the  
>>> object return type.
>>>
>>> Where does "basename" come from on the non-Windows platforms?  It  
>>> was unresolved, so I guessed at it, but which seems to work.
>>>
>>
>> basename is a Unix/Linux function...not standard C or POSIX. Does  
>> Windows have something called _splitpath()?
>>
>>> The c-index-api-test.m test passes on Windows with these changes.
>>
>> Great. Thanks for helping out on this!
>>
>> snaroff
>>
>>>
>>> -John
>>> On Mon, Oct 19, 2009 at 12:14 PM, John Thompson <john.thompson.jtsoftware at gmail.com 
>>> > wrote:
>>> I'm looking at a test failure of c-index-api-test.m on Windows,  
>>> and I've run into a problem I don't know how to easily fix.
>>>
>>> In the function Selector::getAsString function in  
>>> IdentifierTable.cpp at line 330:
>>>
>>>     return II->getName().str() + ":";
>>>
>>> On Windows, at least, this isn't working as expected.  I think  
>>> it's because a tempory string created gets destructed before the  
>>> return completes, causing the resulting string pointer to point to  
>>> garbage, resulting in garbage for the identifier name in the index  
>>> output.
>>>
>>> If someone more knowlegeable about it could take a look at it, I'd  
>>> appreciate it.
>>>
>>> Note that if you need to run it on windows, you'll need some  
>>> CIndex changes I'm working on, but haven't completed yet, so let  
>>> me know if you need them.
>>>
>>> -John
>>>
>>> -- 
>>> John Thompson
>>> John.Thompson.JTSoftware at gmail.com
>>>
>>>
>>>
>>>
>>> -- 
>>> John Thompson
>>> John.Thompson.JTSoftware at gmail.com
>>>
>>> <cindex.patch>_______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>>
>> -- 
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>> <cindex_string.patch><cindex_imports.patch>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/89ac5dae/attachment.html 

From fjahanian at apple.com  Tue Oct 20 15:25:40 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Tue, 20 Oct 2009 13:25:40 -0700
Subject: [cfe-dev] Selector::getAsString problem in CIndex
In-Reply-To: <5C277B15-06F0-4B73-86A1-475F5047C35D@apple.com>
References: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>
	<aad8390910200803v2d598a97y6fad4fccf592e198@mail.gmail.com>
	<AC3E6E17-6F34-453D-9661-74FE887829A3@apple.com>
	<aad8390910201215o25e0b979jc361501adab1b416@mail.gmail.com>
	<5C277B15-06F0-4B73-86A1-475F5047C35D@apple.com>
Message-ID: <7765EEF1-5121-4790-B3E5-DA56E6E58130@apple.com>


On Oct 20, 2009, at 12:43 PM, steve naroff wrote:

> Hi John,
>
> The patch didn't apply for me (it's based on yesterday's source).  
> Could you update it?
>
> On the string lifetime issue...after consulting with Daniel, we'd  
> prefer to avoid cluttering up the API to deal with lazily computed  
> names (that aren't part of the AST per se).
>
> One spin on your change...
>
> +// For temporary string returns.
> +static char CIBuffer[256];
> +
>
> ...is to have a static llvm::StringSet that contains copies of the  
> strings. For example:
>
> static llvm::StringSet<> LazilyComputedShortLivedNames;
>
> While this is more general than your change (no limit, can hold an  
> arbitrary # of strings), it is static data (which is less than great).
>
> It would be nice if this data were cached per-Index. Unfortunately,  
> this would require either (a) more bookkeeping or (b) more explicit  
> 'CXIndex' arguments be passed around.
>
> So...it seem like the choices are:
>
> (a) static StringSet<> to keep the API simple (i.e. no requirement  
> on the client to size/deal with strings).
> (b) per-index StringSet<> to keep the string API simple. Modify the  
> API to pass CXIndex in more places.
> (c) per-index StringSet<> to keep the string API simple. Add  
> bookkeeping to navigate from a CXDecl->CXTranslationUnit->CXIndex.
> (d) Avoid passing back C strings entirely (what I previously said  
> we'd like to avoid). Complicates the API, but makes the contract  
> very explicit.
> (e) Go with your change (documenting the limitations).
>
> At the moment, this is primarily a problem with ObjC names (i.e.  
> Selectors), however this will be an issues for C++ as well I believe  
> (for names that contain type info).
>
If the names, such as selectors, are globally unique, it makes sense  
to go with a). Unless, per-index naming is needed for functionality  
reasons.

- Fariborz


From snaroff at apple.com  Tue Oct 20 15:33:56 2009
From: snaroff at apple.com (steve naroff)
Date: Tue, 20 Oct 2009 16:33:56 -0400
Subject: [cfe-dev] Selector::getAsString problem in CIndex
In-Reply-To: <7765EEF1-5121-4790-B3E5-DA56E6E58130@apple.com>
References: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>
	<aad8390910200803v2d598a97y6fad4fccf592e198@mail.gmail.com>
	<AC3E6E17-6F34-453D-9661-74FE887829A3@apple.com>
	<aad8390910201215o25e0b979jc361501adab1b416@mail.gmail.com>
	<5C277B15-06F0-4B73-86A1-475F5047C35D@apple.com>
	<7765EEF1-5121-4790-B3E5-DA56E6E58130@apple.com>
Message-ID: <60D36964-8DF6-4A0A-9AC1-DEDF4872EDD0@apple.com>


On Oct 20, 2009, at 4:25 PM, Fariborz Jahanian wrote:

>
> On Oct 20, 2009, at 12:43 PM, steve naroff wrote:
>
>> Hi John,
>>
>> The patch didn't apply for me (it's based on yesterday's source).  
>> Could you update it?
>>
>> On the string lifetime issue...after consulting with Daniel, we'd  
>> prefer to avoid cluttering up the API to deal with lazily computed  
>> names (that aren't part of the AST per se).
>>
>> One spin on your change...
>>
>> +// For temporary string returns.
>> +static char CIBuffer[256];
>> +
>>
>> ...is to have a static llvm::StringSet that contains copies of the  
>> strings. For example:
>>
>> static llvm::StringSet<> LazilyComputedShortLivedNames;
>>
>> While this is more general than your change (no limit, can hold an  
>> arbitrary # of strings), it is static data (which is less than  
>> great).
>>
>> It would be nice if this data were cached per-Index. Unfortunately,  
>> this would require either (a) more bookkeeping or (b) more explicit  
>> 'CXIndex' arguments be passed around.
>>
>> So...it seem like the choices are:
>>
>> (a) static StringSet<> to keep the API simple (i.e. no requirement  
>> on the client to size/deal with strings).
>> (b) per-index StringSet<> to keep the string API simple. Modify the  
>> API to pass CXIndex in more places.
>> (c) per-index StringSet<> to keep the string API simple. Add  
>> bookkeeping to navigate from a CXDecl->CXTranslationUnit->CXIndex.
>> (d) Avoid passing back C strings entirely (what I previously said  
>> we'd like to avoid). Complicates the API, but makes the contract  
>> very explicit.
>> (e) Go with your change (documenting the limitations).
>>
>> At the moment, this is primarily a problem with ObjC names (i.e.  
>> Selectors), however this will be an issues for C++ as well I  
>> believe (for names that contain type info).
>>
> If the names, such as selectors, are globally unique, it makes sense  
> to go with a). Unless, per-index naming is needed for functionality  
> reasons.
>

Makes sense, however it's not just functionality.

I'm also concerned about reclaiming the string pool. If it's static, I  
can't reclaim it. If it's per-index, clang_disposeIndex() could  
reclaim it.

snaroff

> - Fariborz
>


From john.thompson.jtsoftware at gmail.com  Tue Oct 20 18:32:39 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 20 Oct 2009 16:32:39 -0700
Subject: [cfe-dev] Selector::getAsString problem in CIndex
In-Reply-To: <5C277B15-06F0-4B73-86A1-475F5047C35D@apple.com>
References: <aad8390910191214p31538ce9v2e789a4df4f87694@mail.gmail.com>
	<aad8390910200803v2d598a97y6fad4fccf592e198@mail.gmail.com>
	<AC3E6E17-6F34-453D-9661-74FE887829A3@apple.com>
	<aad8390910201215o25e0b979jc361501adab1b416@mail.gmail.com>
	<5C277B15-06F0-4B73-86A1-475F5047C35D@apple.com>
Message-ID: <aad8390910201632v4428ab25if54d5ecfe746f8f5@mail.gmail.com>

Steve,

Here's another patch for the DLL imports part of it, redone on the current
versions.  I made a change to it, however, inputting the _CMAKE_LIB_
definition for triggering the export verses import via a flag from the build
instead of the CIndex.cpp file.  This might avoid confusion in the future
if additional files are added later to the DLL.
For the rest, I'll wait to hear from you.

-John
On Tue, Oct 20, 2009 at 12:43 PM, steve naroff <snaroff at apple.com> wrote:

> Hi John,
> The patch didn't apply for me (it's based on yesterday's source). Could you
> update it?
>
> On the string lifetime issue...after consulting with Daniel, we'd prefer to
> avoid cluttering up the API to deal with lazily computed names (that aren't
> part of the AST per se).
>
> One spin on your change...
>
>  +// For temporary string returns.
> +static char CIBuffer[256];
> +
>
> ...is to have a static llvm::StringSet that contains copies of the strings.
> For example:
>
> static llvm::StringSet<> LazilyComputedShortLivedNames;
>
> While this is more general than your change (no limit, can hold an
> arbitrary # of strings), it is static data (which is less than great).
>
> It would be nice if this data were cached per-Index. Unfortunately, this
> would require either (a) more bookkeeping or (b) more explicit 'CXIndex'
> arguments be passed around.
>
> So...it seem like the choices are:
>
> (a) static StringSet<> to keep the API simple (i.e. no requirement on the
> client to size/deal with strings).
> (b) per-index StringSet<> to keep the string API simple. Modify the API to
> pass CXIndex in more places.
> (c) per-index StringSet<> to keep the string API simple. Add bookkeeping to
> navigate from a CXDecl->CXTranslationUnit->CXIndex.
> (d) Avoid passing back C strings entirely (what I previously said we'd like
> to avoid). Complicates the API, but makes the contract very explicit.
> (e) Go with your change (documenting the limitations).
>
> At the moment, this is primarily a problem with ObjC names (i.e.
> Selectors), however this will be an issues for C++ as well I believe (for
> names that contain type info).
>
> As a result, I want to get other opinions on this before we make a
> decision.
>
> Thanks much,
>
> snaroff
>
>   On Oct 20, 2009, at 3:15 PM, John Thompson wrote:
>
>   Here it is separated into two patches.  cindex_imports has the DLL stuff
> plus the basename fix.  cindex_string has the string fixes plus the function
> move.  cindex_string depends on cindex_imports.  (The only overlapping part
> is the CIndex.cpp _CINDEX_CPP_ definition in cindex_imports.)
>
> Looking at _splitpath, it seems that my basename is more convenient to use,
> since _splitpath breaks the path up into separate drive, dir, fname, and ext
> strings, which need separate buffers.  I'd also be concerned as to whether
> it will work with unix-style '/' directory separators, whereas mine works
> with both.
> -John
> On Tue, Oct 20, 2009 at 8:36 AM, steve naroff <snaroff at apple.com> wrote:
>
>> Hi John,
>> Comments below...
>>
>>  On Oct 20, 2009, at 11:03 AM, John Thompson wrote:
>>
>>  Now that I have electricity again...
>>
>> Sorry, I was looking too deep, not noticing that the function returned a
>> std::string.  The problem was up higher in CIndex.cpp, in a couple of the
>> functions that return const char *, with the same problem I described of the
>> temporary going away before the string can be used.
>>
>>
>>
>> Nice catch. I guess other platforms are more forgiving...
>>
>>  I worked around it by using a static buffer, which is admittedly not so
>> good.  A cleaner way might be to have the user pass in a string buffer,
>> since it seems this needs to be a C interface.  Should I do that, or does
>> the API need to remain unchanged?  Let me know if there's a better way.
>>
>>
>>
>> I'd like to avoid cluttering the interface if possible. I'm not an expert
>> on std::String, so I'll have to look into this. I'll get back to you...
>>
>>  The enclosed patch contains my hacked version, which also includes the
>> DLL exporting glue (redone in the naming style I'm used to - apologies to
>> Jeff Krall, who'd already done it).
>>
>>
>>
>> Can you separate this from the other stuff in the patch? I'd like to keep
>> this type of mechanical change separate from the trickier stuff...
>>
>>  Note that I moved the getLocationFromCursor function out of the extern
>> "C" {} because MSVC was complaining about it because of the object return
>> type.
>>
>> Where does "basename" come from on the non-Windows platforms?  It was
>> unresolved, so I guessed at it, but which seems to work.
>>
>>
>>
>> basename is a Unix/Linux function...not standard C or POSIX. Does Windows
>> have something called _splitpath()?
>>
>>  The c-index-api-test.m test passes on Windows with these changes.
>>
>>
>> Great. Thanks for helping out on this!
>>
>> snaroff
>>
>>
>> -John
>> On Mon, Oct 19, 2009 at 12:14 PM, John Thompson <
>> john.thompson.jtsoftware at gmail.com> wrote:
>>
>>> I'm looking at a test failure of c-index-api-test.m on Windows, and I've
>>> run into a problem I don't know how to easily fix.
>>>
>>> In the function Selector::getAsString function in IdentifierTable.cpp at
>>> line 330:
>>>
>>>     return II->getName().str() + ":";
>>>
>>> On Windows, at least, this isn't working as expected.  I think
>>> it's because a tempory string created gets destructed before the return
>>> completes, causing the resulting string pointer to point to garbage,
>>> resulting in garbage for the identifier name in the index output.
>>>
>>> If someone more knowlegeable about it could take a look at it, I'd
>>> appreciate it.
>>>
>>> Note that if you need to run it on windows, you'll need some CIndex
>>> changes I'm working on, but haven't completed yet, so let me know if you
>>> need them.
>>>
>>> -John
>>>
>>> --
>>> John Thompson
>>> John.Thompson.JTSoftware at gmail.com
>>>
>>>
>>
>>
>> --
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>> <cindex.patch>_______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> <cindex_string.patch><cindex_imports.patch>
>
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/b6c8b63f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cindex_imports_1.patch
Type: application/octet-stream
Size: 15585 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091020/b6c8b63f/attachment-0001.obj 

From clattner at apple.com  Tue Oct 20 23:40:04 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Oct 2009 21:40:04 -0700
Subject: [cfe-dev] ext_vector_type cg-gen crash on x86-64 and some
	questions on the ABI
In-Reply-To: <hbilld$qv4$1@ger.gmane.org>
References: <hbilld$qv4$1@ger.gmane.org>
Message-ID: <E9A85529-AF65-40AA-940E-FF56F94D4849@apple.com>

On Oct 19, 2009, at 2:28 PM, Mattias Holm wrote:

> I have some code that simplified is:
>

This seems to work with clang mainline, at least with 'clang t.c -c -O  
-m64'

> Now some questions on the semantics of the ext_vector_type, since it  
> is
> not that well documented in the clang extensions page.
>
> 1. What is the ABI for an ext_vector_type? Will the vectors be  
> passed in
> SSE registers if they are passed as function arguments, or will they  
> be
> passed by address?

vectors that correspond to SSE types (e.g. 4 x float) should be passed  
and returned in sse registers.

> 2. Sizeof (float3) returns 12 and not 16 as I would have guessed for
> alignment reasons, why is this the case? Assuming you want to use SSE
> for computing with the vectors, they must be aligned IIRC.

That is really bad, please file a bug.  We don't really maintain a  
stable ABI for non-native vector types, so we can fix this.

-Chris

From holm at liacs.nl  Wed Oct 21 00:48:04 2009
From: holm at liacs.nl (Mattias Holm)
Date: Wed, 21 Oct 2009 07:48:04 +0200
Subject: [cfe-dev] ext_vector_type cg-gen crash on x86-64 and some
 questions on the ABI
In-Reply-To: <E9A85529-AF65-40AA-940E-FF56F94D4849@apple.com>
References: <hbilld$qv4$1@ger.gmane.org>
	<E9A85529-AF65-40AA-940E-FF56F94D4849@apple.com>
Message-ID: <hbm7ak$uru$1@ger.gmane.org>

Chris Lattner wrote:
> On Oct 19, 2009, at 2:28 PM, Mattias Holm wrote:
> 
>> I have some code that simplified is:
>>
> 
> This seems to work with clang mainline, at least with 'clang t.c -c -O  
> -m64'

OK, great. I will update my clang to trunk.

>> 2. Sizeof (float3) returns 12 and not 16 as I would have guessed for
>> alignment reasons, why is this the case? Assuming you want to use SSE
>> for computing with the vectors, they must be aligned IIRC.
> 
> That is really bad, please file a bug.  We don't really maintain a  
> stable ABI for non-native vector types, so we can fix this.

Done, filed as bug #5265.

Regards,
Mattias


From clattner at apple.com  Wed Oct 21 01:23:17 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Oct 2009 23:23:17 -0700
Subject: [cfe-dev] patch for generalizing stdint for n-bit bytes
In-Reply-To: <8F2E4A8BCDA0B84DA6C9088EB5B277478448A6@NAMAIL.ad.onsemi.com>
References: <BB76172E-1804-45DC-AB55-18EAB0F0F41F@gmail.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B27747844567@NAMAIL.ad.onsemi.com>
	<6a8523d60910191448i3cbe3eam928a2fd8ee32d98f@mail.gmail.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B277478448A6@NAMAIL.ad.onsemi.com>
Message-ID: <5AADD75D-DDCB-409C-AF92-0C72A75B587D@apple.com>

On Oct 20, 2009, at 9:22 AM, Ken Dyck wrote:
>>> If it helps, I'd be happy to separate the new test cases and the
>>> raw_ostream conversion into separate patches.
>>
>> Yes, that would probably be very helpful!
>
> Attached are patches for the stdint.h/InitPreprocessor.cpp  
> modifications and some new tests that exercise preprocessor  
> initialization.

Hi Ken,

This is very interesting work!

First, TargetInfo.h/cpp: these look great.  I applied these as r  
except for this hunk:

+++ lib/Basic/TargetInfo.cpp	(working copy)
@@ -67,12 +67,63 @@
    case SignedInt:        return "int";
    case UnsignedInt:      return "unsigned int";
    case SignedLong:       return "long int";
-  case UnsignedLong:     return "long unsigned int";
+  case UnsignedLong:     return "unsigned long int";
    case SignedLongLong:   return "long long int";
-  case UnsignedLongLong: return "long long unsigned int";
+  case UnsignedLongLong: return "unsigned long long int";
    }
  }

Is this needed or just cleanup?


Please propose a patch that just uses the new methods you added to  
simplify InitPreprocessor without changing the other behavior.  That  
will make it easier to review the patch and it will be more obviously  
correct (and can thus be applied without thinking) :)


The changes to stdint.h are difficult to understand from the patch,  
but look basically reasonable to me.  In the next round of patches,  
I'll look closer.  Just to verify, on boring targets where bytes are 8  
bits, no extra definitions will come out of it (other than the new  
WIDTH macros)?

The testcases are very nice: please merge them together into one test  
that uses multiple RUN lines and uses a different -check-prefix to  
FileCheck.  Also, the RUN lines don't need to fit into 80 columns,  
please use "clang-cc -E ... | FileCheck %s" instead of using %t.

A minor issue, please don't use "const TargetInfo& TI", please use  
"const TargetInfo &TI".

-Chris

From john.thompson.jtsoftware at gmail.com  Wed Oct 21 07:38:18 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 21 Oct 2009 05:38:18 -0700
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
Message-ID: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>

Devang,

On Windows, the 2009-10-20-GlobalDebug.c test fails.  Is it because debug
info is not yet supported on Windows?  If so, how could this test be set up
to not fail?
-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/1aacf7e0/attachment.html 

From rdivacky at freebsd.org  Wed Oct 21 07:41:31 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Wed, 21 Oct 2009 14:41:31 +0200
Subject: [cfe-dev] -B support in clang
Message-ID: <20091021124131.GA52937@freebsd.org>

hi

I am trying this command:

CC='clang -m32 -march=native -mfancy-math-387 -DCOMPAT_32BIT  -iprefix
/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/
-L/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/lib32
-B/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/lib32' mkdep -f .depend -a    -DHAVE_CONFIG_H
-I/data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/..
-I/data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp
-I/data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC
/data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c

but it fails with:

clang: error: unsupported option '-B/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/lib32'


so.. is -B supported? I tried to search for the option definitions but 
I failed badly :(

thank you, roman

From snaroff at apple.com  Wed Oct 21 07:54:21 2009
From: snaroff at apple.com (steve naroff)
Date: Wed, 21 Oct 2009 08:54:21 -0400
Subject: [cfe-dev] -B support in clang
In-Reply-To: <20091021124131.GA52937@freebsd.org>
References: <20091021124131.GA52937@freebsd.org>
Message-ID: <55AB9B45-C016-4ADE-A106-5571D303B327@apple.com>

Hi Roman,

I don't believe it is currently supported. I found a FIXME below which  
relates to -B:

Compilation *Driver::BuildCompilation(int argc, const char **argv) {
   llvm::PrettyStackTraceString CrashInfo("Compilation construction");

   // FIXME: Handle environment options which effect driver behavior,  
somewhere
   // (client?). GCC_EXEC_PREFIX, COMPILER_PATH, LIBRARY_PATH, LPATH,
   // CC_PRINT_OPTIONS.

snaroff

On Oct 21, 2009, at 8:41 AM, Roman Divacky wrote:

> hi
>
> I am trying this command:
>
> CC='clang -m32 -march=native -mfancy-math-387 -DCOMPAT_32BIT  -iprefix
> /home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/
> -L/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/lib32
> -B/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/lib32'  
> mkdep -f .depend -a    -DHAVE_CONFIG_H
> -I/data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/..
> -I/data/home/rdivacky/clangbsd/gnu/lib/libssp/ 
> libssp_nonshared/../../../../contrib/gcclibs/libssp
> -I/data/home/rdivacky/clangbsd/gnu/lib/libssp/ 
> libssp_nonshared/../../../../contrib/gcclibs/include -DPIC
> /data/home/rdivacky/clangbsd/gnu/lib/libssp/ 
> libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c
>
> but it fails with:
>
> clang: error: unsupported option '-B/home/rdivacky/tmp//data/home/ 
> rdivacky/clangbsd/lib32/usr/lib32'
>
>
> so.. is -B supported? I tried to search for the option definitions but
> I failed badly :(
>
> thank you, roman
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/6ee21b1a/attachment.html 

From Fons.Rademakers at cern.ch  Wed Oct 21 09:01:46 2009
From: Fons.Rademakers at cern.ch (Fons Rademakers)
Date: Wed, 21 Oct 2009 16:01:46 +0200
Subject: [cfe-dev] partial specializations of member templates style +
	traceback...
Message-ID: <4ADF144A.8050901@cern.ch>

Hi (Doug),

    any idea when this will be no longer an assert:

clang-cc: 
/home/rdm/llvm/src/tools/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:419: 
clang::Decl*<unnamed>::TemplateDeclInstantiator::VisitClassTemplatePartialSpecializationDecl(clang::ClassTemplatePartialSpecializationDecl*): 
Assertion `false &&"Partial specializations of member templates are 
unsupported"' failed.
0   clang-cc        0x00000000010d7416
1   clang-cc        0x00000000010d79fc
2   libpthread.so.0 0x0000003eb5c0e7c0
3   libc.so.6       0x0000003eb5030265 gsignal + 53
4   libc.so.6       0x0000003eb5031d10 abort + 272
5   libc.so.6       0x0000003eb50296e6 __assert_fail + 246
6   clang-cc        0x00000000007d5405
7   clang-cc        0x00000000007d9371
8   clang-cc        0x00000000007d9708
9   clang-cc        0x00000000007ce78d
10  clang-cc        0x00000000007cfce0
11  clang-cc        0x00000000007dc70b
12  clang-cc        0x00000000006cf299
13  clang-cc        0x0000000000796eb1
14  clang-cc        0x00000000007b77fa
15  clang-cc        0x00000000007c0ebd
16  clang-cc        0x00000000007bdfbe
17  clang-cc        0x00000000007c210c
18  clang-cc        0x00000000007d6767
19  clang-cc        0x00000000007d9303
20  clang-cc        0x00000000007d9708
21  clang-cc        0x00000000007ce78d
22  clang-cc        0x00000000007cfce0
23  clang-cc        0x00000000007dc70b
24  clang-cc        0x00000000006cf299
25  clang-cc        0x0000000000770ecd
26  clang-cc        0x00000000006f519b
27  clang-cc        0x000000000089484d
28  clang-cc        0x000000000089d8c2
29  clang-cc        0x000000000089e46c
30  clang-cc        0x000000000089f664
31  clang-cc        0x00000000008956fc
32  clang-cc        0x000000000088c355
33  clang-cc        0x000000000088cf84
34  clang-cc        0x000000000088d038
35  clang-cc        0x00000000006bfc2b
36  clang-cc        0x0000000000429912
37  clang-cc        0x000000000042bab7 main + 3203
38  libc.so.6       0x0000003eb501d994 __libc_start_main + 244
39  clang-cc        0x0000000000421f69
Stack dump:
0.      Program arguments: /home/rdm/llvm/inst/bin/../libexec/clang-cc 
-triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free 
-main-file-name TGeoPatternFinder.h --relocation-model static 
--disable-fp-elim --unwind-tables=1 --mcpu=x86-64 --fmath-errno=1 
-D_REENTRANT -I/home/rdm/root/include 
-I/usr/include/c++/4.1.2/x86_64-redhat-linux -pthread -fexceptions 
-fdiagnostics-show-option -x c++ root/include/TGeoPatternFinder.h
1.      /home/rdm/root/include/TGeoElement.h:325:12: at annotation token
2.      /home/rdm/root/include/TGeoElement.h:315:1: parsing 
struct/union/class body 'TGeoElementTable'
clang: error: compiler command failed due to signal 6 (use -v to see 
invocation)

It is basically the only remaining header parse error for our system.

Also it looks like the Linux traceback is not fully implemented. Is 
somebody working on this? Of course for MacOS the traceback is complete.

Cheers, Fons.

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640

From ssen at apple.com  Wed Oct 21 10:34:04 2009
From: ssen at apple.com (Shantonu Sen)
Date: Wed, 21 Oct 2009 08:34:04 -0700
Subject: [cfe-dev] -B support in clang
In-Reply-To: <55AB9B45-C016-4ADE-A106-5571D303B327@apple.com>
References: <20091021124131.GA52937@freebsd.org>
	<55AB9B45-C016-4ADE-A106-5571D303B327@apple.com>
Message-ID: <89A1F58D-7508-4477-99A0-BBD2309FA064@apple.com>

I have to ask: what are you really trying to do?

GCC's build system (which I assume where the libssp is being taken from) uses -B internally to override default search paths for the *uninstalled* xgcc. If you're trying to build libssp with a preinstalled compiler (either gcc or clang), -B is not appropriate, because the compiler will find whatever it needs in /usr/lib. In fact, overriding the paths with something pointing to a partial gcc build might do more harm than good.

Shantonu

Sent from my MacBook

On Oct 21, 2009, at 5:54 AM, steve naroff wrote:

> Hi Roman,
> 
> I don't believe it is currently supported. I found a FIXME below which relates to -B:
> 
> Compilation *Driver::BuildCompilation(int argc, const char **argv) {
>   llvm::PrettyStackTraceString CrashInfo("Compilation construction");
> 
>   // FIXME: Handle environment options which effect driver behavior, somewhere
>   // (client?). GCC_EXEC_PREFIX, COMPILER_PATH, LIBRARY_PATH, LPATH,
>   // CC_PRINT_OPTIONS.
> 
> snaroff
> 
> On Oct 21, 2009, at 8:41 AM, Roman Divacky wrote:
> 
>> hi
>> 
>> I am trying this command:
>> 
>> CC='clang -m32 -march=native -mfancy-math-387 -DCOMPAT_32BIT  -iprefix
>> /home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/
>> -L/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/lib32
>> -B/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/lib32' mkdep -f .depend -a    -DHAVE_CONFIG_H
>> -I/data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/..
>> -I/data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp
>> -I/data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC
>> /data/home/rdivacky/clangbsd/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c
>> 
>> but it fails with:
>> 
>> clang: error: unsupported option '-B/home/rdivacky/tmp//data/home/rdivacky/clangbsd/lib32/usr/lib32'
>> 
>> 
>> so.. is -B supported? I tried to search for the option definitions but 
>> I failed badly :(
>> 
>> thank you, roman
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/21c144f6/attachment.html 

From dgregor at apple.com  Wed Oct 21 10:55:57 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 21 Oct 2009 08:55:57 -0700
Subject: [cfe-dev] partial specializations of member templates style +
	traceback...
In-Reply-To: <4ADF144A.8050901@cern.ch>
References: <4ADF144A.8050901@cern.ch>
Message-ID: <1E804FF1-D41A-4413-91D7-FBAF81C22AFC@apple.com>


On Oct 21, 2009, at 7:01 AM, Fons Rademakers wrote:

> Hi (Doug),
>
>    any idea when this will be no longer an assert:
>
> clang-cc:
> /home/rdm/llvm/src/tools/clang/lib/Sema/ 
> SemaTemplateInstantiateDecl.cpp:419:
> clang 
> ::Decl 
> *< 
> unnamed 
> > 
> ::TemplateDeclInstantiator 
> ::VisitClassTemplatePartialSpecializationDecl 
> (clang::ClassTemplatePartialSpecializationDecl*):
> Assertion `false &&"Partial specializations of member templates are
> unsupported"' failed.
> 0

> [snip]
> It is basically the only remaining header parse error for our system.

You can track this issue here:

	http://llvm.org/bugs/show_bug.cgi?id=5236

> Also it looks like the Linux traceback is not fully implemented. Is
> somebody working on this? Of course for MacOS the traceback is  
> complete.


I don't know of anyone working on this.

	- Doug

From dpatel at apple.com  Wed Oct 21 11:31:07 2009
From: dpatel at apple.com (Devang Patel)
Date: Wed, 21 Oct 2009 09:31:07 -0700
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
In-Reply-To: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
References: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
Message-ID: <D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>


On Oct 21, 2009, at 5:38 AM, John Thompson wrote:

> Devang,
>
> On Windows, the 2009-10-20-GlobalDebug.c test fails.  Is it because  
> debug info is not yet supported on Windows?

Is that the real reason ? I do not know.

> If so, how could this test be set up to not fail?

Is it possible to xfail or xtarget this test ?
-
Devang
> -John
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/fa24e154/attachment.html 

From dgregor at apple.com  Wed Oct 21 12:54:33 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 21 Oct 2009 10:54:33 -0700
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
In-Reply-To: <D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>
References: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
	<D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>
Message-ID: <0C323D76-1CBD-4511-BCA0-1231801206D8@apple.com>


On Oct 21, 2009, at 9:31 AM, Devang Patel wrote:

>
> On Oct 21, 2009, at 5:38 AM, John Thompson wrote:
>
>> Devang,
>>
>> On Windows, the 2009-10-20-GlobalDebug.c test fails.  Is it because  
>> debug info is not yet supported on Windows?
>
> Is that the real reason ? I do not know.
>
>> If so, how could this test be set up to not fail?
>
> Is it possible to xfail or xtarget this test ?

You could just force the triple...

	- Doug

From rdivacky at freebsd.org  Wed Oct 21 13:12:24 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Wed, 21 Oct 2009 20:12:24 +0200
Subject: [cfe-dev] -B support in clang
In-Reply-To: <89A1F58D-7508-4477-99A0-BBD2309FA064@apple.com>
References: <20091021124131.GA52937@freebsd.org>
	<55AB9B45-C016-4ADE-A106-5571D303B327@apple.com>
	<89A1F58D-7508-4477-99A0-BBD2309FA064@apple.com>
Message-ID: <20091021181224.GA2007@freebsd.org>

On Wed, Oct 21, 2009 at 08:34:04AM -0700, Shantonu Sen wrote:
> I have to ask: what are you really trying to do?
> 
> GCC's build system (which I assume where the libssp is being taken from) uses -B internally to override default search paths for the *uninstalled* xgcc. If you're trying to build libssp with a preinstalled compiler (either gcc or clang), -B is not appropriate, because the compiler will find whatever it needs in /usr/lib. In fact, overriding the paths with something pointing to a partial gcc build might do more harm than good.

we're building freebsd, this includes building gcc... I am currently 
investigating how to do this in a different way

From dgregor at apple.com  Wed Oct 21 13:49:01 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 21 Oct 2009 11:49:01 -0700
Subject: [cfe-dev] Mingw compiling error
In-Reply-To: <806065d90910161831u41f13f1ai6f322c3abbe54f24@mail.gmail.com>
References: <806065d90910161831u41f13f1ai6f322c3abbe54f24@mail.gmail.com>
Message-ID: <DE5B29C4-F474-4B6A-865E-01F233C6B330@apple.com>


On Oct 16, 2009, at 6:31 PM, ???(Yonggang Luo) wrote:

> [ 93%] Building CXX object tools/clang/lib/Frontend/CMakeFiles/ 
> clangFrontend.dir/ASTConsumers.cpp.obj
> cd D:\objs\llvm\eclipse\tools\clang\lib\Frontend && D:\Tools\Building 
> \gcc\bin\g++.exe   -D_DEBUG -D__STDC_LIMIT_MACROS - 
> D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -fno-common -Woverloaded- 
> virtual -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter - 
> Wwrite-strings -ID:\objs\llvm\eclipse\include -IE:\Downloads\llvm- 
> trunk\include -IE:\Downloads\llvm-trunk\tools\clang\include -ID:\objs 
> \llvm\eclipse\tools\clang\include   -o CMakeFiles\clangFrontend.dir 
> \ASTConsumers.cpp.obj -c E:\Downloads\llvm-trunk\tools\clang\lib 
> \Frontend\ASTConsumers.cpp
> D:\Tools\Building\cmake\bin\cmake.exe -E cmake_progress_report D: 
> \objs\llvm\eclipse\CMakeFiles 86
> [ 94%] Building CXX object tools/clang/lib/Frontend/CMakeFiles/ 
> clangFrontend.dir/ASTUnit.cpp.obj
> cd D:\objs\llvm\eclipse\tools\clang\lib\Frontend && D:\Tools\Building 
> \gcc\bin\g++.exe   -D_DEBUG -D__STDC_LIMIT_MACROS - 
> D__STDC_CONSTANT_MACROS -D_GNU_SOURCE -fno-common -Woverloaded- 
> virtual -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter - 
> Wwrite-strings -ID:\objs\llvm\eclipse\include -IE:\Downloads\llvm- 
> trunk\include -IE:\Downloads\llvm-trunk\tools\clang\include -ID:\objs 
> \llvm\eclipse\tools\clang\include   -o CMakeFiles\clangFrontend.dir 
> \ASTUnit.cpp.obj -c E:\Downloads\llvm-trunk\tools\clang\lib\Frontend 
> \ASTUnit.cpp
> E:\Downloads\llvm-trunk\tools\clang\lib\Frontend\ASTUnit.cpp: In  
> destructor 'clang::ASTUnit::~ASTUnit()':
> E:\Downloads\llvm-trunk\tools\clang\lib\Frontend\ASTUnit.cpp:30:  
> error: 'unlink' was not declared in this scope
> mingw32-make[2]: *** [tools/clang/lib/Frontend/CMakeFiles/ 
> clangFrontend.dir/ASTUnit.cpp.obj] Error 1
> mingw32-make[2]: Leaving directory `D:/objs/llvm/eclipse'
> mingw32-make[1]: *** [tools/clang/lib/Frontend/CMakeFiles/ 
> clangFrontend.dir/all] Error 2
> mingw32-make[1]: Leaving directory `D:/objs/llvm/eclipse'

This should have been fixed, here:

	http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091012/022511.html

	- Doug

From john.thompson.jtsoftware at gmail.com  Wed Oct 21 14:05:05 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 21 Oct 2009 12:05:05 -0700
Subject: [cfe-dev] disabling MS extensions on some tests
Message-ID: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>

By adding -fms-extensions=0 to some of the tests previously failing on
Windows, it makes these 6 tests pass on Windows.

The question is, are these legitimate differences between the default Clang
behavior and MSVC?

They seem sort of reasonable, but I'm not knowledgeable enough to say for
sure.

The enclosed patch contains these changes.

Here is the previous test output:

1>********************
1>FAIL: Clang::SemaTemplate/nested-name-spec-template.cpp (1664 of 1692)
1>******************** TEST
'Clang::SemaTemplate/nested-name-spec-template.cpp' FAILED
********************
1>Script:
1>--
1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp
1>--
1>Exit Code: 1
1>Command Output (stdout):
1>--
1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
"-verify"
"C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp"
1>Command 0 Result: 1
1>Command 0 Output:
1>Command 0 Stderr:
1>Errors expected but not seen:
1>  Line 34: C++ requires a type specifier for all declarations
1>Warnings seen but not expected:
1>  Line 34: type specifier missing, defaults to 'int'
1>--
1>Command Output (stderr):
1>--
1>--
1>********************
1>FAIL: Clang::Preprocessor/line-directive.c (903 of 1692)
1>******************** TEST 'Clang::Preprocessor/line-directive.c' FAILED
********************
1>Script:
1>--
1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify -pedantic
C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c
1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E
C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c 2>&1 | grep
'blonk.c:92:2: error: #error ABC'
1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E
C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c 2>&1 | grep
'blonk.c:93:2: error: #error DEF'
1>--
1>Exit Code: 1
1>Command Output (stdout):
1>--
1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
"-verify" "-pedantic"
"C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c"
1>Command 0 Result: 1
1>Command 0 Output:
1>Command 0 Stderr:
1>Errors expected but not seen:
1>  Line 44: redefinition of typedef 'x' is invalid in C
1>  Line 65: redefinition of typedef 'w' is invalid in C
1>Notes expected but not seen:
1>  Line 43: previous definition is here
1>  Line 64: previous definition is here
1>--
1>Command Output (stderr):
1>--
1>--
1>********************
1>FAIL: Clang::Parser/cxx-template-decl.cpp (793 of 1692)
1>******************** TEST 'Clang::Parser/cxx-template-decl.cpp' FAILED
********************
1>Script:
1>--
1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
C:\Tools\llvm\tools\clang\test\Parser\cxx-template-decl.cpp
1>--
1>Exit Code: 1
1>Command Output (stdout):
1>--
1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
"-verify" "C:\Tools\llvm\tools\clang\test\Parser\cxx-template-decl.cpp"
1>Command 0 Result: 1
1>Command 0 Output:
1>Command 0 Stderr:
1>Errors expected but not seen:
1>  Line 5: C++ requires a type specifier for all declarations
1>  Line 57: declaration of 'T' shadows template parameter
1>  Line 61: declaration of 'T' shadows template parameter
1>  Line 64: declaration of 'T' shadows template parameter
1>  Line 68: declaration of 'Size' shadows template parameter
1>  Line 73: shadows
1>  Line 78: shadows
1>Warnings seen but not expected:
1>  Line 5: type specifier missing, defaults to 'int'
1>Notes expected but not seen:
1>  Line 56: template parameter is declared here
1>  Line 60: template parameter is declared here
1>  Line 63: template parameter is declared here
1>  Line 67: template parameter is declared here
1>  Line 71: here
1>  Line 76: here
1>--
1>Command Output (stderr):
1>--
1>--
1>********************
1>FAIL: Clang::SemaCXX/implicit-int.cpp (1290 of 1692)
1>******************** TEST 'Clang::SemaCXX/implicit-int.cpp' FAILED
********************
1>Script:
1>--
1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp
1>--
1>Exit Code: 1
1>Command Output (stdout):
1>--
1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
"-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp"
1>Command 0 Result: 1
1>Command 0 Output:
1>Command 0 Stderr:
1>Errors expected but not seen:
1>  Line 3: C++ requires a type specifier for all declarations
1>  Line 5: C++ requires a type specifier for all declarations
1>Warnings seen but not expected:
1>  Line 3: type specifier missing, defaults to 'int'
1>  Line 5: type specifier missing, defaults to 'int'
1>--
1>Command Output (stderr):
1>--
1>--
1>********************
1>FAIL: Clang::SemaCXX/typedef-redecl.cpp (1352 of 1692)
1>******************** TEST 'Clang::SemaCXX/typedef-redecl.cpp' FAILED
********************
1>Script:
1>--
1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp
1>--
1>Exit Code: 1
1>Command Output (stdout):
1>--
1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
"-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp"
1>Command 0 Result: 1
1>Command 0 Output:
1>Command 0 Stderr:
1>Errors expected but not seen:
1>  Line 10: redefinition of 'result_type'
1>Notes expected but not seen:
1>  Line 9: previous definition is here
1>--
1>Command Output (stderr):
1>--
1>--
1>********************
1>FAIL: Clang::SemaCXX/nested-name-spec.cpp (1309 of 1692)
1>******************** TEST 'Clang::SemaCXX/nested-name-spec.cpp' FAILED
********************
1>Script:
1>--
1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -std=c++98 -verify
C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp
1>--
1>Exit Code: 1
1>Command Output (stdout):
1>--
1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
"-std=c++98" "-verify"
"C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp"
1>Command 0 Result: 1
1>Command 0 Output:
1>Command 0 Stderr:
1>Errors expected but not seen:
1>  Line 171: C++ requires a type specifier for all declarations
1>  Line 192: C++ requires a type specifier for all declarations
1>Errors seen but not expected:
1>  Line 195: cannot initialize 'a3' with an lvalue of type 'int'
1>Warnings seen but not expected:
1>  Line 171: type specifier missing, defaults to 'int'
1>  Line 192: type specifier missing, defaults to 'int'
1>--
1>Command Output (stderr):
1>--
1>--


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/ad2faee6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noms.patch
Type: application/octet-stream
Size: 2558 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/ad2faee6/attachment-0001.obj 

From john.thompson.jtsoftware at gmail.com  Wed Oct 21 14:25:01 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 21 Oct 2009 12:25:01 -0700
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
In-Reply-To: <0C323D76-1CBD-4511-BCA0-1231801206D8@apple.com>
References: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
	<D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>
	<0C323D76-1CBD-4511-BCA0-1231801206D8@apple.com>
Message-ID: <aad8390910211225s7861d2fap7e4b86951f3afd76@mail.gmail.com>

Hmmm, I tried passing -Xclang "-triple=i686-pc-linux-gnu" to clang.exe, but
apparently it conflicts with a -target directive the driver puts in.  But
I'm not sure this is the proper format.  The driver didn't like just
"-target=i686-pc-linux-gnu" either.

Is this a bug in the driver, not checking for options being overidden?
What does the -dA option do?  I don't see it in "clang -help".

Which triple should it be using?

Here's the command output, with the triple option and a -v also:

FAIL: Clang::CodeGen/2009-10-20-GlobalDebug.c (1 of 1)
******************** TEST 'Clang::CodeGen/2009-10-20-GlobalDebug.c' FAILED
********************
Script:
--
C:/Tools/llvm/bin/Debug\clang.EXE -S -g -dA -Xclang
"-triple=i686-pc-linux-gnu" -v
C:\Tools\llvm\tools\clang\test\CodeGen\2009-10-20-GlobalDebug.c -o - |
FileCheck C:\Tools\llvm\tools\clang\test\CodeGen\2009-10-20-GlobalDebug.c
--
Exit Code: 1
Command Output (stdout):
--
Command 0: "C:/Tools/llvm/bin/Debug\clang.EXE" "-S" "-g" "-dA" "-Xclang"
"-triple=i686-pc-linux-gnu" "-v"
"C:\Tools\llvm\tools\clang\test\CodeGen\2009-10-20-GlobalDebug.c" "-o" "-"
Command 0 Result: 1
Command 0 Output:

Command 0 Stderr:
clang version 1.1 (trunk 84674)
Target: i686-pc-win32
Thread model: posix
 "C:/Tools/llvm/bin/Debug/clang-cc.exe" -triple i686-pc-win32 -S
-disable-free -main-file-name 2009-10-20-GlobalDebug.c --relocation-model
static --disable-fp-elim --asm-verbose --unwind-tables=0 --fmath-errno=1 -v
-g -fexceptions=0 -fdiagnostics-show-option -triple=i686-pc-linux-gnu -o -
-x c C:\Tools\llvm\tools\clang\test\CodeGen\2009-10-20-GlobalDebug.c
clang-cc.exe: for the -triple option: may only occur zero or one times!

Command 1: "FileCheck"
"C:\Tools\llvm\tools\clang\test\CodeGen\2009-10-20-GlobalDebug.c"
Command 1 Result: 1
Command 1 Output:

Command 1 Stderr:
C:\Tools\llvm\tools\clang\test\CodeGen\2009-10-20-GlobalDebug.c:3:52: error:
expected string not found in input
// CHECK: asciz "global" ## DW_AT_MIPS_linkage_name
                                                   ^
<stdin>:1:1: note: scanning from here
^

--
Command Output (stderr):
--
--

On Wed, Oct 21, 2009 at 10:54 AM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Oct 21, 2009, at 9:31 AM, Devang Patel wrote:
>
>
>> On Oct 21, 2009, at 5:38 AM, John Thompson wrote:
>>
>> Devang,
>>>
>>> On Windows, the 2009-10-20-GlobalDebug.c test fails.  Is it because debug
>>> info is not yet supported on Windows?
>>>
>>
>> Is that the real reason ? I do not know.
>>
>> If so, how could this test be set up to not fail?
>>>
>>
>> Is it possible to xfail or xtarget this test ?
>>
>
> You could just force the triple...
>
>        - Doug
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/450c66e6/attachment.html 

From benny.kra at googlemail.com  Wed Oct 21 15:05:00 2009
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Wed, 21 Oct 2009 22:05:00 +0200
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
In-Reply-To: <aad8390910211225s7861d2fap7e4b86951f3afd76@mail.gmail.com>
References: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
	<D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>
	<0C323D76-1CBD-4511-BCA0-1231801206D8@apple.com>
	<aad8390910211225s7861d2fap7e4b86951f3afd76@mail.gmail.com>
Message-ID: <79E3A1C8-CB15-44D1-951B-802A247137D3@gmail.com>


Am 21.10.2009 um 21:25 schrieb John Thompson:

> Hmmm, I tried passing -Xclang "-triple=i686-pc-linux-gnu" to  
> clang.exe, but
> apparently it conflicts with a -target directive the driver puts  
> in.  But
> I'm not sure this is the proper format.  The driver didn't like just
> "-target=i686-pc-linux-gnu" either.

There is "-ccc-host-triple" to override the triple passed to clang-cc.

> Is this a bug in the driver, not checking for options being overidden?
> What does the -dA option do?  I don't see it in "clang -help".

verbose assembly

> Which triple should it be using?

The test was failing on all non-darwin platforms so I forced the  
triple to i386-apple-darwin10 in r84777.

From clattner at apple.com  Wed Oct 21 15:18:57 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 21 Oct 2009 13:18:57 -0700
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
In-Reply-To: <79E3A1C8-CB15-44D1-951B-802A247137D3@gmail.com>
References: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
	<D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>
	<0C323D76-1CBD-4511-BCA0-1231801206D8@apple.com>
	<aad8390910211225s7861d2fap7e4b86951f3afd76@mail.gmail.com>
	<79E3A1C8-CB15-44D1-951B-802A247137D3@gmail.com>
Message-ID: <C43A9ABC-DF4B-45F5-9E3B-45425F342361@apple.com>


On Oct 21, 2009, at 1:05 PM, Benjamin Kramer wrote:

>
> Am 21.10.2009 um 21:25 schrieb John Thompson:
>
>> Hmmm, I tried passing -Xclang "-triple=i686-pc-linux-gnu" to
>> clang.exe, but
>> apparently it conflicts with a -target directive the driver puts
>> in.  But
>> I'm not sure this is the proper format.  The driver didn't like just
>> "-target=i686-pc-linux-gnu" either.
>
> There is "-ccc-host-triple" to override the triple passed to clang-cc.
>
>> Is this a bug in the driver, not checking for options being  
>> overidden?
>> What does the -dA option do?  I don't see it in "clang -help".
>
> verbose assembly
>
>> Which triple should it be using?
>
> The test was failing on all non-darwin platforms so I forced the
> triple to i386-apple-darwin10 in r84777.

Forcing the triple is fairly brute force. Does it work if you change  
the check line to:

// CHECK: asciz "global" {{.*}}DW_AT_MIPS_linkage_name

?

-Chris

From benny.kra at googlemail.com  Wed Oct 21 15:30:25 2009
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Wed, 21 Oct 2009 22:30:25 +0200
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
In-Reply-To: <C43A9ABC-DF4B-45F5-9E3B-45425F342361@apple.com>
References: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
	<D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>
	<0C323D76-1CBD-4511-BCA0-1231801206D8@apple.com>
	<aad8390910211225s7861d2fap7e4b86951f3afd76@mail.gmail.com>
	<79E3A1C8-CB15-44D1-951B-802A247137D3@gmail.com>
	<C43A9ABC-DF4B-45F5-9E3B-45425F342361@apple.com>
Message-ID: <FADFC764-A140-4E57-9A6A-CC5F9A9D80E5@gmail.com>


Am 21.10.2009 um 22:18 schrieb Chris Lattner:

>
> On Oct 21, 2009, at 1:05 PM, Benjamin Kramer wrote:
>
>>
>> Am 21.10.2009 um 21:25 schrieb John Thompson:
>>
>>> Hmmm, I tried passing -Xclang "-triple=i686-pc-linux-gnu" to
>>> clang.exe, but
>>> apparently it conflicts with a -target directive the driver puts
>>> in.  But
>>> I'm not sure this is the proper format.  The driver didn't like just
>>> "-target=i686-pc-linux-gnu" either.
>>
>> There is "-ccc-host-triple" to override the triple passed to clang- 
>> cc.
>>
>>> Is this a bug in the driver, not checking for options being  
>>> overidden?
>>> What does the -dA option do?  I don't see it in "clang -help".
>>
>> verbose assembly
>>
>>> Which triple should it be using?
>>
>> The test was failing on all non-darwin platforms so I forced the
>> triple to i386-apple-darwin10 in r84777.
>
> Forcing the triple is fairly brute force. Does it work if you change  
> the check line to:
>
> // CHECK: asciz "global" {{.*}}DW_AT_MIPS_linkage_name


I chose to force the triple because I wasn't sure if all targets use  
"asciz" for string literals.

From john.thompson.jtsoftware at gmail.com  Wed Oct 21 16:08:15 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 21 Oct 2009 14:08:15 -0700
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
In-Reply-To: <FADFC764-A140-4E57-9A6A-CC5F9A9D80E5@gmail.com>
References: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
	<D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>
	<0C323D76-1CBD-4511-BCA0-1231801206D8@apple.com>
	<aad8390910211225s7861d2fap7e4b86951f3afd76@mail.gmail.com>
	<79E3A1C8-CB15-44D1-951B-802A247137D3@gmail.com>
	<C43A9ABC-DF4B-45F5-9E3B-45425F342361@apple.com>
	<FADFC764-A140-4E57-9A6A-CC5F9A9D80E5@gmail.com>
Message-ID: <aad8390910211408o14d8f2e2wd021435a48cc22fb@mail.gmail.com>

 > I chose to force the triple because I wasn't sure if all targets use
"asciz" for string literals.
There's no asciz.  Here's the output:

 .section .debug_frame,"dr"
$section_debug_frame:
 .section .debug_info,"dr"
$section_info:
 .section .debug_abbrev,"dr"
$section_abbrev:
 .section .debug_aranges,"dr"
$section_aranges:
 .section .debug_macinfo,"dr"
$section_macinfo:
 .section .debug_line,"dr"
$section_line:
 .section .debug_loc,"dr"
$section_loc:
 .section .debug_pubnames,"dr"
$section_pubnames:
 .section .debug_str,"dr"
$section_str:
 .section .debug_ranges,"dr"
$section_ranges:
 .text
$text_begin:
 .data
$data_begin:

 .text
 ALIGN 16
 .globl _main
_main:                                                      ; @main
; BB#0:                                                     ; %entry
 pushl %ebp
$label1:
 movl %esp, %ebp
$label2:
 subl $4, %esp
$label3:
 movl $0, -4(%ebp)
 movl $0, -4(%ebp)                                ; SrcLine 4:14
 movl -4(%ebp), %eax                              ; SrcLine 4:14
 addl $4, %esp                                    ; SrcLine 4:14
 popl %ebp                                        ; SrcLine 4:14
 ret                                                 ; SrcLine 4:14
 .section .data$linkonce_global,"w"
 .comm _global,4,4                                 ; @global

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/3e7baf91/attachment.html 

From clattner at apple.com  Wed Oct 21 17:33:12 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 21 Oct 2009 15:33:12 -0700
Subject: [cfe-dev] 2009-10-20-GlobalDebug.c failing on Windows
In-Reply-To: <aad8390910211408o14d8f2e2wd021435a48cc22fb@mail.gmail.com>
References: <aad8390910210538u59361a24na3da839876393349@mail.gmail.com>
	<D18B6C7C-916D-466D-B47D-3A213B066956@apple.com>
	<0C323D76-1CBD-4511-BCA0-1231801206D8@apple.com>
	<aad8390910211225s7861d2fap7e4b86951f3afd76@mail.gmail.com>
	<79E3A1C8-CB15-44D1-951B-802A247137D3@gmail.com>
	<C43A9ABC-DF4B-45F5-9E3B-45425F342361@apple.com>
	<FADFC764-A140-4E57-9A6A-CC5F9A9D80E5@gmail.com>
	<aad8390910211408o14d8f2e2wd021435a48cc22fb@mail.gmail.com>
Message-ID: <842B3A99-53D9-4674-B101-0AFED84BBB3E@apple.com>


On Oct 21, 2009, at 2:08 PM, John Thompson wrote:

>  > I chose to force the triple because I wasn't sure if all targets  
> use "asciz" for string literals.
> There's no asciz.  Here's the output:

Ok, no debug info at all, lets go with a forced triple.

-Chris

>
>  .section .debug_frame,"dr"
> $section_debug_frame:
>  .section .debug_info,"dr"
> $section_info:
>  .section .debug_abbrev,"dr"
> $section_abbrev:
>  .section .debug_aranges,"dr"
> $section_aranges:
>  .section .debug_macinfo,"dr"
> $section_macinfo:
>  .section .debug_line,"dr"
> $section_line:
>  .section .debug_loc,"dr"
> $section_loc:
>  .section .debug_pubnames,"dr"
> $section_pubnames:
>  .section .debug_str,"dr"
> $section_str:
>  .section .debug_ranges,"dr"
> $section_ranges:
>  .text
> $text_begin:
>  .data
> $data_begin:
>
>  .text
>  ALIGN 16
>  .globl _main
> _main:                                                      ; @main
> ; BB#0:                                                     ; %entry
>  pushl %ebp
> $label1:
>  movl %esp, %ebp
> $label2:
>  subl $4, %esp
> $label3:
>  movl $0, -4(%ebp)
>  movl $0, -4(%ebp)                                ; SrcLine 4:14
>  movl -4(%ebp), %eax                              ; SrcLine 4:14
>  addl $4, %esp                                    ; SrcLine 4:14
>  popl %ebp                                        ; SrcLine 4:14
>  ret                                                 ; SrcLine 4:14
>  .section .data$linkonce_global,"w"
>  .comm _global,4,4                                 ; @global
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/7952cc83/attachment-0001.html 

From lattner at apple.com  Wed Oct 21 17:44:34 2009
From: lattner at apple.com (Tanya Lattner)
Date: Wed, 21 Oct 2009 15:44:34 -0700
Subject: [cfe-dev] 2.6 pre-release2 testing ends today
Message-ID: <28F3F76C-CE0C-49F2-B574-0F2D65FC3CBA@apple.com>

Just a reminder that today is the last day for pre-release2 testing.

Thanks,
Tanya

From john.thompson.jtsoftware at gmail.com  Wed Oct 21 21:26:59 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 21 Oct 2009 19:26:59 -0700
Subject: [cfe-dev] XFAIL and XTARGET
Message-ID: <aad8390910211926h5f0e9a3dl616ec23520916774@mail.gmail.com>

How are XFAIL and XTARGET supposed to work in a test?

It would be nice if these were documented on the Testing Infrustructure
page.

In looking at the TestRunner.py file, it seems that you should be able to
put something this this in a test to tell it that the test is expected to
fail on Windows:

// XFAIL: i686-pc-win32,x86_64-pc-win32

 But it seems that regardless of what I put after XFAIL, the test comes out
as an expected failure if the test fails, or an unexpected pass if the test
passes.  I've been bouncing between Linux and Windows trying different
things.  It seems that only "// XFAIL" is currently used.

I don't know Python enough to really understand what should be happening.

Basically, the Driver/hello.c test doesn't pass on Windows.  I though if I
put MinGW gcc in the PATH it might pass, but I get the following errors from
just running the compile command line:

C:\Tools\llvm\tools\clang\test>clang -ccc-echo -v -o tmp.o Driver/hello.c
clang version 1.1 (trunk 84674)
Target: i686-pc-win32
Thread model: posix
 "C:/Tools/llvm/bin/Debug/clang-cc.exe" -triple i686-pc-win32 -S
-disable-free -main-file-name hello.c --relocation-model static --disable-f
p-elim --unwind-tables=0 --fmath-errno=1 -v -fexceptions=0
-fdiagnostics-show-option -o C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s
-x c D
river/hello.c
clang-cc version 1.1 based upon llvm 2.7svn hosted on i686-pc-win32
ignoring nonexistent directory "c:\Program Files\Microsoft Visual Studio
9.0\VC\PlatformSDK\Include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/System/Library/Frameworks"
ignoring nonexistent directory "/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 C:/Tools/llvm/bin/lib/clang/1.1/include
 c:\Program Files\Microsoft Visual Studio 9.0\VC\include
 /usr/include
End of search list.
 "c:/mingw/bin/gcc.exe" -v -c -o
C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000001.o -x assembler
C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --enable-shared --e
nable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefi
x=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root
--build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-o'
'C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000001.o' '-mtune=i386'
 c:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/as.exe -o
C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000001.o C:/DOCUME~1/fcadmin/L
OCALS~1/Temp/cc-000000.s
C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s: Assembler messages:
C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s:4: Error: no such instruction:
`align 16'
C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s:20: Error: no such
instruction: `align 16'
C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s:22: Error: no such
instruction: `db "I'm a little driver, short and stout.\000"'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/67d9a06f/attachment.html 

From john.thompson.jtsoftware at gmail.com  Wed Oct 21 22:02:42 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 21 Oct 2009 20:02:42 -0700
Subject: [cfe-dev] running the tests on MinGW
Message-ID: <aad8390910212002p2cbfd297qb25d0bcb510ce979@mail.gmail.com>

It's cool that clang builds on MinGW now after a generic ./configure.  Thaks
to whoever got it working.

I'm having a problem running the tests, however:

$ make
Making Clang 'lit.site.cfg' file...
--- Running clang tests for i686-pc-mingw32 ---
lit.py: TestingConfig.py:48: fatal: unable to load config from
'/home/llvm/tools/clang/test/../test/lit.cfg'
make: *** [all] Error 2
Doing an "ls -l /home/llvm/tools/clang/test/../test/lit.cfg" finds the file,
so I.

I'm using python 2.6.2 from a Windows distribution.  I couldn't find a
ready-built python for MinGW, so I tried unsuccessfully to build the
sources.  Should my Windows python work?

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091021/c3cef7a1/attachment.html 

From max at duempel.org  Thu Oct 22 03:42:51 2009
From: max at duempel.org (Max Kellermann)
Date: Thu, 22 Oct 2009 10:42:51 +0200
Subject: [cfe-dev] Bug: false positive on -Wmissing-noreturn
Message-ID: <20091022084251.GA6329@squirrel.roonstrasse.net>

Hi,

I'm using clang from svn trunk r84843.  I'm getting the following
false warning message:

 clang -Wmissing-noreturn -c noreturn.c
 noreturn.c:4:1: warning: function could be attribute 'noreturn'
 [-Wmissing-noreturn]

See attached source code.  It is obvious that the function can return,
since the compiler must not make assumptions on the return values of
foo().

Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noreturn.c
Type: text/x-csrc
Size: 87 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/4916dbc0/attachment.bin 

From isanbard at gmail.com  Thu Oct 22 05:09:32 2009
From: isanbard at gmail.com (Bill Wendling)
Date: Thu, 22 Oct 2009 03:09:32 -0700
Subject: [cfe-dev] [LLVMdev] 2.6 pre-release2 testing ends today
In-Reply-To: <28F3F76C-CE0C-49F2-B574-0F2D65FC3CBA@apple.com>
References: <28F3F76C-CE0C-49F2-B574-0F2D65FC3CBA@apple.com>
Message-ID: <5187C08D-736E-4627-9791-18D092BD71BD@gmail.com>

On Oct 21, 2009, at 3:44 PM, Tanya Lattner wrote:

> Just a reminder that today is the last day for pre-release2 testing.
>
Hi Tanya,

Attached are the log files for Mac OS X 10.5.8 on PowerPC. There are  
these failures for clang:

********************
Failing Tests (20):
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/ 
always_inline.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/ 
bitfield-promote.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/call- 
knr-indirect.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/inline.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/lineno- 
dbginfo.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/no- 
common.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/stack- 
protector.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/ 
clang_cpp.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/ 
clang_f_opts.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/hello.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/pth.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/redzone.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Frontend/ 
dependency-gen.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Lexer/counter.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Misc/message- 
length.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/PCH/pr4489.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Preprocessor/ 
print_line_count.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Sema/ 
transparent-union.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Sema/warn- 
unused-parameters.c
         /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/SemaObjC/class- 
property-access.m

Otherwise, the testing went well. Though I don't have testing for the  
llvm-test suite. I forgot to run them. :-(

-bw


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Debug.check.log
Type: application/octet-stream
Size: 31056 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/c97b807c/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Release-Asserts.check.log
Type: application/octet-stream
Size: 31066 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/c97b807c/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Release.check.log
Type: application/octet-stream
Size: 31058 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/c97b807c/attachment-0005.obj 
-------------- next part --------------



From Ken.Dyck at onsemi.com  Thu Oct 22 07:12:36 2009
From: Ken.Dyck at onsemi.com (Ken Dyck)
Date: Thu, 22 Oct 2009 05:12:36 -0700
Subject: [cfe-dev] patch for generalizing stdint for n-bit bytes
In-Reply-To: <5AADD75D-DDCB-409C-AF92-0C72A75B587D@apple.com>
References: <BB76172E-1804-45DC-AB55-18EAB0F0F41F@gmail.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B27747844567@NAMAIL.ad.onsemi.com>
	<6a8523d60910191448i3cbe3eam928a2fd8ee32d98f@mail.gmail.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B277478448A6@NAMAIL.ad.onsemi.com>
	<5AADD75D-DDCB-409C-AF92-0C72A75B587D@apple.com>
Message-ID: <8F2E4A8BCDA0B84DA6C9088EB5B27747844FBF@NAMAIL.ad.onsemi.com>

On Wednesday, October 21, 2009 2:23 AM, Chris Lattner wrote:
> On Oct 20, 2009, at 9:22 AM, Ken Dyck wrote:
> > Attached are patches for the stdint.h/InitPreprocessor.cpp 
> > modifications and some new tests that exercise preprocessor 
> > initialization.
> 
> First, TargetInfo.h/cpp: these look great.  I applied these 
> as r except for this hunk:
> 
> +++ lib/Basic/TargetInfo.cpp	(working copy)
> @@ -67,12 +67,63 @@
>     case SignedInt:        return "int";
>     case UnsignedInt:      return "unsigned int";
>     case SignedLong:       return "long int";
> -  case UnsignedLong:     return "long unsigned int";
> +  case UnsignedLong:     return "unsigned long int";
>     case SignedLongLong:   return "long long int";
> -  case UnsignedLongLong: return "long long unsigned int";
> +  case UnsignedLongLong: return "unsigned long long int";
>     }
>   }
> 
> Is this needed or just cleanup?

More of an unrelated fix. Neither "long unsigned int" nor "long long
unsigned int" are listed among the acceptable type specifiers in section
6.7.2 of C99 or section 7.1.5.2 of C++98. Clang obviously must handle
them correctly, but I figured changing them could only improve
portability.

> Please propose a patch that just uses the new methods you 
> added to simplify InitPreprocessor without changing the other 
> behavior.  That will make it easier to review the patch and 
> it will be more obviously correct (and can thus be applied 
> without thinking) :)

Is the attached patch what you have in mind? Or would you like to see a
more aggressive refactoring to remove all of the literal type names and
constant suffixes from InitPreprocessor.cpp?

> The changes to stdint.h are difficult to understand from the 
> patch, but look basically reasonable to me.  In the next 
> round of patches, I'll look closer.  Just to verify, on 
> boring targets where bytes are 8 bits, no extra definitions 
> will come out of it (other than the new WIDTH macros)?

There aren't any additional user macros, but there are a few more
implementation macros. Some are for the SIG_ATOMIC definitions, which
were previously hard-coded as 32-bit integers. There are also some new
SIGNED macros so stdint.h can define the correct limits for the types
that can can be either signed or unsigned.

> The testcases are very nice: please merge them together into 
> one test that uses multiple RUN lines and uses a different 
> -check-prefix to FileCheck.  Also, the RUN lines don't need 
> to fit into 80 columns, please use "clang-cc -E ... | 
> FileCheck %s" instead of using %t.

How about two tests: one to test stdint.h and the other to test basic
preprocessor initialization? That is what is in the attached patch,
anyways.

The patch corresponds to the current stdint.h, so it can be applied
safely now, with (or without) the InitPreprocessor.cpp changes in the
other patch. This will provide a baseline for evaluating further changes
to stdint.h and InitPreprocessor.cpp.

Cheers,
-Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InitPreprocessor-simplify.r84758.patch
Type: application/octet-stream
Size: 1617 bytes
Desc: InitPreprocessor-simplify.r84758.patch
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/0226bc4b/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpp-tests-pre-stdint-mods.r84758.patch
Type: application/octet-stream
Size: 77337 bytes
Desc: cpp-tests-pre-stdint-mods.r84758.patch
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/0226bc4b/attachment-0003.obj 

From fjahanian at apple.com  Thu Oct 22 10:59:22 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Thu, 22 Oct 2009 08:59:22 -0700
Subject: [cfe-dev] Bug: false positive on -Wmissing-noreturn
In-Reply-To: <20091022084251.GA6329@squirrel.roonstrasse.net>
References: <20091022084251.GA6329@squirrel.roonstrasse.net>
Message-ID: <E953926B-CCA9-4C6F-88DC-79DA45A1B0B2@apple.com>

Looks like a clang bug please file a bug report.  Warning also needs  
improvement; something like:

'function will not return and is a candidate to be declared with  
'noreturn' attribute.
- Fariborz


- Fariborz

On Oct 22, 2009, at 1:42 AM, Max Kellermann wrote:

> Hi,
>
> I'm using clang from svn trunk r84843.  I'm getting the following
> false warning message:
>
> clang -Wmissing-noreturn -c noreturn.c
> noreturn.c:4:1: warning: function could be attribute 'noreturn'
> [-Wmissing-noreturn]
>
> See attached source code.  It is obvious that the function can return,
> since the compiler must not make assumptions on the return values of
> foo().
>
> Max
> <noreturn.c>_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From clattner at apple.com  Thu Oct 22 11:25:43 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 22 Oct 2009 09:25:43 -0700
Subject: [cfe-dev] [LLVMdev] 2.6 pre-release2 testing ends today
In-Reply-To: <5187C08D-736E-4627-9791-18D092BD71BD@gmail.com>
References: <28F3F76C-CE0C-49F2-B574-0F2D65FC3CBA@apple.com>
	<5187C08D-736E-4627-9791-18D092BD71BD@gmail.com>
Message-ID: <DF5B5577-23CB-4CB1-8F37-28461C6A9F05@apple.com>


On Oct 22, 2009, at 3:09 AM, Bill Wendling wrote:

> On Oct 21, 2009, at 3:44 PM, Tanya Lattner wrote:
>
>> Just a reminder that today is the last day for pre-release2 testing.
>>
> Hi Tanya,
>
> Attached are the log files for Mac OS X 10.5.8 on PowerPC. There are  
> these failures for clang:

Clang doesn't support PowerPC, so this is ok.

-Chris

>
> ********************
> Failing Tests (20):
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/ 
> always_inline.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/ 
> bitfield-promote.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/call- 
> knr-indirect.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/inline.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/lineno- 
> dbginfo.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/no- 
> common.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/CodeGen/stack- 
> protector.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/ 
> clang_cpp.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/ 
> clang_f_opts.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/hello.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/pth.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Driver/redzone.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Frontend/ 
> dependency-gen.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Lexer/counter.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Misc/message- 
> length.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/PCH/pr4489.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Preprocessor/ 
> print_line_count.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Sema/ 
> transparent-union.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/Sema/warn- 
> unused-parameters.c
>        /Volumes/SandBox/2.6/llvm-2.6/tools/clang/test/SemaObjC/class- 
> property-access.m
>
> Otherwise, the testing went well. Though I don't have testing for  
> the llvm-test suite. I forgot to run them. :-(
>
> -bw
>
>
> <Debug.check.log><Release-Asserts.check.log><Release.check.log>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From raila at illinois.edu  Thu Oct 22 13:25:53 2009
From: raila at illinois.edu (david raila)
Date: Thu, 22 Oct 2009 13:25:53 -0500
Subject: [cfe-dev] Initial tokens
Message-ID: <4AE0A3B1.7020504@illinois.edu>


If I parse an empty file with a few breakpoints set to watch what's going on
I see that there must be something predefined to give 25 calls to  
ConsumeToken for
example.  What are they and where are these pushed in?
Thanks,
dkr


(gdb) inf br
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000008e4d67 in 
clang::Parser::ParseDeclarator(clang::Declarator&) at ParseDecl.cpp:2087
         breakpoint already hit 6 times
2       breakpoint     keep y   0x00000000008df779 in 
clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&, 
clang::Parser::ParsedTemplateInfo const&) at ParseDecl.cpp:402
         breakpoint already hit 2 times
3       breakpoint     keep y   0x00000000008dc169 in 
clang::Parser::ConsumeToken() at 
/home/raila/dpc++/clang/llvm/tools/clang/lib/Parse/../../include/clang/Parse/Parser.h:212
         breakpoint already hit 25 times


From clattner at apple.com  Thu Oct 22 13:21:55 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 22 Oct 2009 11:21:55 -0700
Subject: [cfe-dev] Initial tokens
In-Reply-To: <4AE0A3B1.7020504@illinois.edu>
References: <4AE0A3B1.7020504@illinois.edu>
Message-ID: <9E4C834B-C430-4458-90D3-1D86C608D51D@apple.com>


On Oct 22, 2009, at 11:25 AM, david raila wrote:

>
> If I parse an empty file with a few breakpoints set to watch what's  
> going on
> I see that there must be something predefined to give 25 calls to
> ConsumeToken for
> example.  What are they and where are these pushed in?

I don't understand your debug dump, but it is probably the predefines  
buffer.  You can see it when you use -E.  It is where things like - 
include and -D options get dropped into.

-Chris

> Thanks,
> dkr
>
>
> (gdb) inf br
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep y   0x00000000008e4d67 in
> clang::Parser::ParseDeclarator(clang::Declarator&) at ParseDecl.cpp: 
> 2087
>         breakpoint already hit 6 times
> 2       breakpoint     keep y   0x00000000008df779 in
> clang::Parser::ParseDeclarationAfterDeclarator(clang::Declarator&,
> clang::Parser::ParsedTemplateInfo const&) at ParseDecl.cpp:402
>         breakpoint already hit 2 times
> 3       breakpoint     keep y   0x00000000008dc169 in
> clang::Parser::ConsumeToken() at
> /home/raila/dpc++/clang/llvm/tools/clang/lib/Parse/../../include/ 
> clang/Parse/Parser.h:212
>         breakpoint already hit 25 times
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From john.thompson.jtsoftware at gmail.com  Thu Oct 22 13:47:13 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 22 Oct 2009 11:47:13 -0700
Subject: [cfe-dev] disabling MS extensions on some tests
In-Reply-To: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>
References: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>
Message-ID: <aad8390910221147i22795e7fg444db3a920162a89@mail.gmail.com>

One more:

Index: test/Preprocessor/macro_paste_bcpl_comment.c
===================================================================
--- test/Preprocessor/macro_paste_bcpl_comment.c (revision 84858)
+++ test/Preprocessor/macro_paste_bcpl_comment.c (working copy)
@@ -1,4 +1,4 @@
-// RUN: clang-cc %s -Eonly 2>&1 | grep error
+// RUN: clang-cc %s -Eonly -fms-extensions=0 2>&1 | grep error

 #define COMM1 / ## /
 COMM1

I did a little digging in the code with this one.  On Windows it definitely
does treat /##/ as an extension for Microsoft mode
(see TokenLexer.cpp:467).  Perhaps there is a way to test for both cases,
but I'm not sure how to set it up.  Is there a way to check for grep failing
or an empty file in this case?

-John

On Wed, Oct 21, 2009 at 12:05 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> By adding -fms-extensions=0 to some of the tests previously failing on
> Windows, it makes these 6 tests pass on Windows.
>
> The question is, are these legitimate differences between the default Clang
> behavior and MSVC?
>
> They seem sort of reasonable, but I'm not knowledgeable enough to say for
> sure.
>
> The enclosed patch contains these changes.
>
> Here is the previous test output:
>
> 1>********************
> 1>FAIL: Clang::SemaTemplate/nested-name-spec-template.cpp (1664 of 1692)
> 1>******************** TEST
> 'Clang::SemaTemplate/nested-name-spec-template.cpp' FAILED
> ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
> C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
> "-verify"
> "C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 34: C++ requires a type specifier for all declarations
> 1>Warnings seen but not expected:
> 1>  Line 34: type specifier missing, defaults to 'int'
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::Preprocessor/line-directive.c (903 of 1692)
> 1>******************** TEST 'Clang::Preprocessor/line-directive.c' FAILED
> ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify -pedantic
> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E
> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c 2>&1 | grep
> 'blonk.c:92:2: error: #error ABC'
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E
> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c 2>&1 | grep
> 'blonk.c:93:2: error: #error DEF'
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
> "-verify" "-pedantic"
> "C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 44: redefinition of typedef 'x' is invalid in C
> 1>  Line 65: redefinition of typedef 'w' is invalid in C
> 1>Notes expected but not seen:
> 1>  Line 43: previous definition is here
> 1>  Line 64: previous definition is here
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::Parser/cxx-template-decl.cpp (793 of 1692)
> 1>******************** TEST 'Clang::Parser/cxx-template-decl.cpp' FAILED
> ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
> C:\Tools\llvm\tools\clang\test\Parser\cxx-template-decl.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
> "-verify" "C:\Tools\llvm\tools\clang\test\Parser\cxx-template-decl.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 5: C++ requires a type specifier for all declarations
> 1>  Line 57: declaration of 'T' shadows template parameter
> 1>  Line 61: declaration of 'T' shadows template parameter
> 1>  Line 64: declaration of 'T' shadows template parameter
> 1>  Line 68: declaration of 'Size' shadows template parameter
> 1>  Line 73: shadows
> 1>  Line 78: shadows
> 1>Warnings seen but not expected:
> 1>  Line 5: type specifier missing, defaults to 'int'
> 1>Notes expected but not seen:
> 1>  Line 56: template parameter is declared here
> 1>  Line 60: template parameter is declared here
> 1>  Line 63: template parameter is declared here
> 1>  Line 67: template parameter is declared here
> 1>  Line 71: here
> 1>  Line 76: here
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/implicit-int.cpp (1290 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/implicit-int.cpp' FAILED
> ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
> C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 3: C++ requires a type specifier for all declarations
> 1>  Line 5: C++ requires a type specifier for all declarations
> 1>Warnings seen but not expected:
> 1>  Line 3: type specifier missing, defaults to 'int'
> 1>  Line 5: type specifier missing, defaults to 'int'
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/typedef-redecl.cpp (1352 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/typedef-redecl.cpp' FAILED
> ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
> C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 10: redefinition of 'result_type'
> 1>Notes expected but not seen:
> 1>  Line 9: previous definition is here
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/nested-name-spec.cpp (1309 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/nested-name-spec.cpp' FAILED
> ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -std=c++98 -verify
> C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
> "-std=c++98" "-verify"
> "C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 171: C++ requires a type specifier for all declarations
> 1>  Line 192: C++ requires a type specifier for all declarations
> 1>Errors seen but not expected:
> 1>  Line 195: cannot initialize 'a3' with an lvalue of type 'int'
> 1>Warnings seen but not expected:
> 1>  Line 171: type specifier missing, defaults to 'int'
> 1>  Line 192: type specifier missing, defaults to 'int'
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/22e55f1f/attachment.html 

From clattner at apple.com  Thu Oct 22 15:02:52 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 22 Oct 2009 13:02:52 -0700
Subject: [cfe-dev] disabling MS extensions on some tests
In-Reply-To: <aad8390910221147i22795e7fg444db3a920162a89@mail.gmail.com>
References: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>
	<aad8390910221147i22795e7fg444db3a920162a89@mail.gmail.com>
Message-ID: <7C109357-431E-4C32-8A93-04671F1C335B@apple.com>


On Oct 22, 2009, at 11:47 AM, John Thompson wrote:

> One more:
>
> Index: test/Preprocessor/macro_paste_bcpl_comment.c
> ===================================================================
> --- test/Preprocessor/macro_paste_bcpl_comment.c (revision 84858)
> +++ test/Preprocessor/macro_paste_bcpl_comment.c (working copy)
> @@ -1,4 +1,4 @@
> -// RUN: clang-cc %s -Eonly 2>&1 | grep error
> +// RUN: clang-cc %s -Eonly -fms-extensions=0 2>&1 | grep error
>
>  #define COMM1 / ## /
>  COMM1
>
> I did a little digging in the code with this one.  On Windows it  
> definitely does treat /##/ as an extension for Microsoft mode (see  
> TokenLexer.cpp:467).  Perhaps there is a way to test for both cases,  
> but I'm not sure how to set it up.  Is there a way to check for grep  
> failing or an empty file in this case?

This patch is ok, please commit it.

-Chris

>
> -John
>
> On Wed, Oct 21, 2009 at 12:05 PM, John Thompson <john.thompson.jtsoftware at gmail.com 
> > wrote:
> By adding -fms-extensions=0 to some of the tests previously failing  
> on Windows, it makes these 6 tests pass on Windows.
>
> The question is, are these legitimate differences between the  
> default Clang behavior and MSVC?
>
> They seem sort of reasonable, but I'm not knowledgeable enough to  
> say for sure.
>
> The enclosed patch contains these changes.
>
> Here is the previous test output:
>
> 1>********************
> 1>FAIL: Clang::SemaTemplate/nested-name-spec-template.cpp (1664 of  
> 1692)
> 1>******************** TEST 'Clang::SemaTemplate/nested-name-spec- 
> template.cpp' FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify C:\Tools 
> \llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name- 
> spec-template.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 34: C++ requires a type specifier for all declarations
> 1>Warnings seen but not expected:
> 1>  Line 34: type specifier missing, defaults to 'int'
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::Preprocessor/line-directive.c (903 of 1692)
> 1>******************** TEST 'Clang::Preprocessor/line-directive.c'  
> FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify - 
> pedantic C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E C:\Tools\llvm\tools\clang 
> \test\Preprocessor\line-directive.c 2>&1 | grep 'blonk.c:92:2:  
> error: #error ABC'
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E C:\Tools\llvm\tools\clang 
> \test\Preprocessor\line-directive.c 2>&1 | grep 'blonk.c:93:2:  
> error: #error DEF'
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "-pedantic" "C:\Tools\llvm\tools\clang\test\Preprocessor 
> \line-directive.c"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 44: redefinition of typedef 'x' is invalid in C
> 1>  Line 65: redefinition of typedef 'w' is invalid in C
> 1>Notes expected but not seen:
> 1>  Line 43: previous definition is here
> 1>  Line 64: previous definition is here
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::Parser/cxx-template-decl.cpp (793 of 1692)
> 1>******************** TEST 'Clang::Parser/cxx-template-decl.cpp'  
> FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify C:\Tools 
> \llvm\tools\clang\test\Parser\cxx-template-decl.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "C:\Tools\llvm\tools\clang\test\Parser\cxx-template- 
> decl.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 5: C++ requires a type specifier for all declarations
> 1>  Line 57: declaration of 'T' shadows template parameter
> 1>  Line 61: declaration of 'T' shadows template parameter
> 1>  Line 64: declaration of 'T' shadows template parameter
> 1>  Line 68: declaration of 'Size' shadows template parameter
> 1>  Line 73: shadows
> 1>  Line 78: shadows
> 1>Warnings seen but not expected:
> 1>  Line 5: type specifier missing, defaults to 'int'
> 1>Notes expected but not seen:
> 1>  Line 56: template parameter is declared here
> 1>  Line 60: template parameter is declared here
> 1>  Line 63: template parameter is declared here
> 1>  Line 67: template parameter is declared here
> 1>  Line 71: here
> 1>  Line 76: here
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/implicit-int.cpp (1290 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/implicit-int.cpp' FAILED  
> ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify C:\Tools 
> \llvm\tools\clang\test\SemaCXX\implicit-int.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 3: C++ requires a type specifier for all declarations
> 1>  Line 5: C++ requires a type specifier for all declarations
> 1>Warnings seen but not expected:
> 1>  Line 3: type specifier missing, defaults to 'int'
> 1>  Line 5: type specifier missing, defaults to 'int'
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/typedef-redecl.cpp (1352 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/typedef-redecl.cpp'  
> FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify C:\Tools 
> \llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 10: redefinition of 'result_type'
> 1>Notes expected but not seen:
> 1>  Line 9: previous definition is here
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/nested-name-spec.cpp (1309 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/nested-name-spec.cpp'  
> FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -std=c++98 - 
> verify C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-std=c++98" "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX 
> \nested-name-spec.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 171: C++ requires a type specifier for all declarations
> 1>  Line 192: C++ requires a type specifier for all declarations
> 1>Errors seen but not expected:
> 1>  Line 195: cannot initialize 'a3' with an lvalue of type 'int'
> 1>Warnings seen but not expected:
> 1>  Line 171: type specifier missing, defaults to 'int'
> 1>  Line 192: type specifier missing, defaults to 'int'
> 1>--
> 1>Command Output (stderr):
> 1>--
> 1>--
>
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
>
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/00319e8a/attachment-0001.html 

From john.thompson.jtsoftware at gmail.com  Thu Oct 22 17:19:14 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 22 Oct 2009 15:19:14 -0700
Subject: [cfe-dev] disabling MS extensions on some tests
In-Reply-To: <7C109357-431E-4C32-8A93-04671F1C335B@apple.com>
References: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>
	<aad8390910221147i22795e7fg444db3a920162a89@mail.gmail.com>
	<7C109357-431E-4C32-8A93-04671F1C335B@apple.com>
Message-ID: <aad8390910221519p3c09731ay5046f3c6da6d2f84@mail.gmail.com>

Thanks for looking at this.  I checked it in.

How should I proceed with the others?  Would it be helpful for me to dig
into the code and find the branching areas?  Or will someone else be looking
into the specific cases?
-John
On Thu, Oct 22, 2009 at 1:02 PM, Chris Lattner <clattner at apple.com> wrote:

>
>  On Oct 22, 2009, at 11:47 AM, John Thompson wrote:
>
>  One more:
>
> Index: test/Preprocessor/macro_paste_bcpl_comment.c
> ===================================================================
> --- test/Preprocessor/macro_paste_bcpl_comment.c (revision 84858)
> +++ test/Preprocessor/macro_paste_bcpl_comment.c (working copy)
> @@ -1,4 +1,4 @@
> -// RUN: clang-cc %s -Eonly 2>&1 | grep error
> +// RUN: clang-cc %s -Eonly -fms-extensions=0 2>&1 | grep error
>
>  #define COMM1 / ## /
>  COMM1
>
> I did a little digging in the code with this one.  On Windows it definitely
> does treat /##/ as an extension for Microsoft mode
> (see TokenLexer.cpp:467).  Perhaps there is a way to test for both cases,
> but I'm not sure how to set it up.  Is there a way to check for grep failing
> or an empty file in this case?
>
>
> This patch is ok, please commit it.
>
> -Chris
>
>
> -John
>
> On Wed, Oct 21, 2009 at 12:05 PM, John Thompson <
> john.thompson.jtsoftware at gmail.com> wrote:
>
>> By adding -fms-extensions=0 to some of the tests previously failing on
>> Windows, it makes these 6 tests pass on Windows.
>>
>> The question is, are these legitimate differences between the default
>> Clang behavior and MSVC?
>>
>> They seem sort of reasonable, but I'm not knowledgeable enough to say for
>> sure.
>>
>> The enclosed patch contains these changes.
>>
>> Here is the previous test output:
>>
>> 1>********************
>> 1>FAIL: Clang::SemaTemplate/nested-name-spec-template.cpp (1664 of 1692)
>> 1>******************** TEST
>> 'Clang::SemaTemplate/nested-name-spec-template.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
>> C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify"
>> "C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 34: C++ requires a type specifier for all declarations
>> 1>Warnings seen but not expected:
>> 1>  Line 34: type specifier missing, defaults to 'int'
>> 1>--
>> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::Preprocessor/line-directive.c (903 of 1692)
>> 1>******************** TEST 'Clang::Preprocessor/line-directive.c' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify -pedantic
>> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E
>> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c 2>&1 | grep
>> 'blonk.c:92:2: error: #error ABC'
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E
>> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c 2>&1 | grep
>> 'blonk.c:93:2: error: #error DEF'
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify" "-pedantic"
>> "C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 44: redefinition of typedef 'x' is invalid in C
>> 1>  Line 65: redefinition of typedef 'w' is invalid in C
>> 1>Notes expected but not seen:
>> 1>  Line 43: previous definition is here
>> 1>  Line 64: previous definition is here
>> 1>--
>> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::Parser/cxx-template-decl.cpp (793 of 1692)
>> 1>******************** TEST 'Clang::Parser/cxx-template-decl.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
>> C:\Tools\llvm\tools\clang\test\Parser\cxx-template-decl.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify" "C:\Tools\llvm\tools\clang\test\Parser\cxx-template-decl.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 5: C++ requires a type specifier for all declarations
>> 1>  Line 57: declaration of 'T' shadows template parameter
>> 1>  Line 61: declaration of 'T' shadows template parameter
>> 1>  Line 64: declaration of 'T' shadows template parameter
>> 1>  Line 68: declaration of 'Size' shadows template parameter
>> 1>  Line 73: shadows
>> 1>  Line 78: shadows
>> 1>Warnings seen but not expected:
>> 1>  Line 5: type specifier missing, defaults to 'int'
>> 1>Notes expected but not seen:
>> 1>  Line 56: template parameter is declared here
>> 1>  Line 60: template parameter is declared here
>> 1>  Line 63: template parameter is declared here
>> 1>  Line 67: template parameter is declared here
>> 1>  Line 71: here
>> 1>  Line 76: here
>> 1>--
>> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::SemaCXX/implicit-int.cpp (1290 of 1692)
>> 1>******************** TEST 'Clang::SemaCXX/implicit-int.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
>> C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 3: C++ requires a type specifier for all declarations
>> 1>  Line 5: C++ requires a type specifier for all declarations
>> 1>Warnings seen but not expected:
>> 1>  Line 3: type specifier missing, defaults to 'int'
>> 1>  Line 5: type specifier missing, defaults to 'int'
>> 1>--
>> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::SemaCXX/typedef-redecl.cpp (1352 of 1692)
>> 1>******************** TEST 'Clang::SemaCXX/typedef-redecl.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
>> C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 10: redefinition of 'result_type'
>> 1>Notes expected but not seen:
>> 1>  Line 9: previous definition is here
>> 1>--
>> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::SemaCXX/nested-name-spec.cpp (1309 of 1692)
>> 1>******************** TEST 'Clang::SemaCXX/nested-name-spec.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -std=c++98 -verify
>> C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-std=c++98" "-verify"
>> "C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 171: C++ requires a type specifier for all declarations
>> 1>  Line 192: C++ requires a type specifier for all declarations
>> 1>Errors seen but not expected:
>> 1>  Line 195: cannot initialize 'a3' with an lvalue of type 'int'
>> 1>Warnings seen but not expected:
>> 1>  Line 171: type specifier missing, defaults to 'int'
>> 1>  Line 192: type specifier missing, defaults to 'int'
>> 1>--
>> 1>Command Output (stderr):
>> 1>--
>> 1>--
>>
>>
>> --
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/30cc1142/attachment.html 

From john.thompson.jtsoftware at gmail.com  Thu Oct 22 17:42:07 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 22 Oct 2009 15:42:07 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
Message-ID: <aad8390910221542q608e559aw689dae0ec3e34bdb@mail.gmail.com>

>
>   Also, could someone look at the enclosed patch for stdint.h?  This also
>>> fixes some failing tests, since VC++ doesn't have stdint.h.  Who is point on
>>> this?
>>>
>>
>> I'm not thrilled about using _M_IX86 and _M_X64 to detect what is really a
>> library issue. I guess in the worst case we could have a configure-time
>> check that determines whether we can #include_next <stdint.h>, but
>> that's.... horrible.
>>
>> Unless someone has a better idea... ?
>>
>
I used these symbols because they are implicitly defined to mimic VC++ in 32
and 64-bit mode respectively.  Would substituting a clang-specific implicit
symbol be more acceptible, i.e. "_CLANG_MSVC"?

Or, a stab in the dark, remove the #include, and internally switch the order
of includes in the search path based on the Freestanding flag?  But I don't
know the implications for the other headers Clang provides.

Or, we disable the 7 tests that include stdint.h on Windows (once we have a
mechanism that can do that).

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091022/9e5007bc/attachment.html 

From arelius at gmail.com  Thu Oct 22 19:45:22 2009
From: arelius at gmail.com (Nicholas "Indy" Ray)
Date: Thu, 22 Oct 2009 17:45:22 -0700
Subject: [cfe-dev] ParseTopLevelDecl not returning without extra token.
Message-ID: <b45520600910221745l44a78a6fud3c06d6c6768aba1@mail.gmail.com>

So, I'm working on a C Interpreter using clang, in particular a patch
that allows reading the Lexer's source from a stream. Now in order to
determine when I have a complete statement so I can compile it
immediately I'm manually calling ParseTopLevelDecl and this works for
the most part, except that ParseDeclarationOrFunctionDefinition (among
other functions) requires an additional token after parsing the
complete deceleration before it returns, this is caused by the
ConsumeToken() call when the Tok is a Tok::semi among other places.

The result of this is that the user has to input an additional token
after the statement is complete, which partially defeats the whole
purpose of using the clang::Parser to determine whole and complete
statements. So, any advice on what could be done to allow clang to
return after a complete statement would be appreciated.

Nicholas "Indy" Ray

From daniel at zuster.org  Fri Oct 23 11:10:55 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 23 Oct 2009 09:10:55 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
Message-ID: <6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>

On Thu, Oct 15, 2009 at 5:23 PM, Douglas Gregor <dgregor at apple.com> wrote:
> > Also, could someone look at the enclosed patch for stdint.h?? This also
> > fixes some failing tests, since VC++ doesn't have stdint.h.? Who is point on
> > this?
>
> I'm not thrilled about using _M_IX86 and _M_X64 to detect what is really a
> library issue. I guess in the worst case we could have a configure-time
> check that determines whether we can #include_next <stdint.h>, but
> that's.... horrible.
> Unless someone has a better idea... ?

No configure-time check. :P

We could always invent a clang specific internal define for this,
which targets can set in their predefines. For example,
__STDC_INCLUDES_STDINT__ or so.

 - Daniel

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


From dgregor at apple.com  Fri Oct 23 11:33:48 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Fri, 23 Oct 2009 09:33:48 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
	<6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>
Message-ID: <A4D41316-AA5C-4C13-9647-749A19DC0BD7@apple.com>


On Oct 23, 2009, at 9:10 AM, Daniel Dunbar wrote:

> On Thu, Oct 15, 2009 at 5:23 PM, Douglas Gregor <dgregor at apple.com>  
> wrote:
>>> Also, could someone look at the enclosed patch for stdint.h?  This  
>>> also
>>> fixes some failing tests, since VC++ doesn't have stdint.h.  Who  
>>> is point on
>>> this?
>>
>> I'm not thrilled about using _M_IX86 and _M_X64 to detect what is  
>> really a
>> library issue. I guess in the worst case we could have a configure- 
>> time
>> check that determines whether we can #include_next <stdint.h>, but
>> that's.... horrible.
>> Unless someone has a better idea... ?
>
> No configure-time check. :P
>
> We could always invent a clang specific internal define for this,
> which targets can set in their predefines. For example,
> __STDC_INCLUDES_STDINT__ or so.


It seems to me that target information should be limited to  
information about the ABI, linker, assembler, and other parts of the  
toolchain, but not the (C or C++) standard library, since standard  
libraries are meant to be interchangeable.

However, I have an idea. Clang's <stdint.h> looks like this:

/* If we're hosted, fall back to the system's stdint.h, which might have
  * additional definitions.
  */
#if __STDC_HOSTED__
# include_next <stdint.h>
#else
// our own definitions of <stdint.h>
#endif

why not add new __has_include and __has_include_next preprocessor  
primitives, so that we can *really* detect whether we have a system  
<stdint.h>?

This also gets us closer to eliminating the need for configure :D

	- Doug

From john.thompson.jtsoftware at gmail.com  Fri Oct 23 11:32:04 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Fri, 23 Oct 2009 09:32:04 -0700
Subject: [cfe-dev] message-length.c
In-Reply-To: <aad8390910211258m2ea84dbbr98ad50dbbca4f95f@mail.gmail.com>
References: <aad8390910190856o7b1ec5c4m3d45952a63a3df30@mail.gmail.com>
	<aad8390910211258m2ea84dbbr98ad50dbbca4f95f@mail.gmail.com>
Message-ID: <aad8390910230932i4e8b6cd1y414e47f9801d95c9@mail.gmail.com>

Daniel,

I did some playing around with message-length.c, and I think the '\r''s are
confusing FileCheck.  I think it's the regex function, which is seeing them,
because the file is opened in binary mode.
This seems to be the easy fix:

Index: test/Misc/message-length.c
===================================================================
--- test/Misc/message-length.c (revision 84858)
+++ test/Misc/message-length.c (working copy)
@@ -29,4 +29,4 @@


 // CHECK: FILE:23:78
-// CHECK: {{^  ...// some long comment text and a brace, eh {} $}}
+// CHECK: {{^  ...// some long comment text and a brace, eh {} .$}}
I tried to match things with '\r' in it, but couldn't get it to work.
Alternatively, we could mess with FileCheck, but I was afraid to.  It uses
the MemoryBuffer function to read the file, so it's hard to chang the open
mode there.

-John

On Wed, Oct 21, 2009 at 12:58 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Nudge (1 of 3)
>
>
> On Mon, Oct 19, 2009 at 8:56 AM, John Thompson <
> john.thompson.jtsoftware at gmail.com> wrote:
>
>> Daniel,
>>
>> After updating, I noticed this test newly failing on Windows:
>>
>> 1>********************
>> 1>FAIL: Clang::Misc/message-length.c (728 of 1688)
>> 1>******************** TEST 'Clang::Misc/message-length.c' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug\clang.EXE -fsyntax-only -fmessage-length=72
>> C:\Tools\llvm\tools\clang\test\Misc\message-length.c 2>&1 | FileCheck
>> -strict-whitespace C:\Tools\llvm\tools\clang\test\Misc\message-length.c
>> 1>C:/Tools/llvm/bin/Debug\clang.EXE -fsyntax-only -fmessage-length=1
>> C:\Tools\llvm\tools\clang\test\Misc\message-length.c
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug\clang.EXE" "-fsyntax-only"
>> "-fmessage-length=72" "C:\Tools\llvm\tools\clang\test\Misc\message-length.c"
>> 1>Command 0 Result: 0
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Command 1: "FileCheck" "-strict-whitespace"
>> "C:\Tools\llvm\tools\clang\test\Misc\message-length.c"
>> 1>Command 1 Result: 1
>> 1>Command 1 Output:
>> 1>Command 1 Stderr:
>> 1>C:\Tools\llvm\tools\clang\test\Misc\message-length.c:32:67: error:
>> expected string not found in input
>> 1>// CHECK: {{^  ...// some long comment text and a brace, eh {} $}}
>> 1>                                                                  ^
>> 1><stdin>:18:11: note: scanning from here
>> 1>FILE:23:78: warning: expected 'ON' or 'OFF' or 'DEFAULT' in pragma
>> 1>          ^
>> 1>--
>> 1>Command Output (stderr):
>> 1>--
>> 1>--
>>
>> -John
>>
>> --
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091023/173bbcef/attachment.html 

From john.thompson.jtsoftware at gmail.com  Fri Oct 23 11:56:25 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Fri, 23 Oct 2009 09:56:25 -0700
Subject: [cfe-dev] message-length.c
In-Reply-To: <aad8390910230932i4e8b6cd1y414e47f9801d95c9@mail.gmail.com>
References: <aad8390910190856o7b1ec5c4m3d45952a63a3df30@mail.gmail.com>
	<aad8390910211258m2ea84dbbr98ad50dbbca4f95f@mail.gmail.com>
	<aad8390910230932i4e8b6cd1y414e47f9801d95c9@mail.gmail.com>
Message-ID: <aad8390910230956u22df1177j7cc9af5231716af@mail.gmail.com>

Oh, scratch this.  It doesn't work on Linux.  '.' has to match something.

Perhaps ".?", i.e.:

+// CHECK: {{^  ...// some long comment text and a brace, eh {} .?$}}

-John
On Fri, Oct 23, 2009 at 9:32 AM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Daniel,
>
> I did some playing around with message-length.c, and I think the '\r''s are
> confusing FileCheck.  I think it's the regex function, which is seeing them,
> because the file is opened in binary mode.
> This seems to be the easy fix:
>
> Index: test/Misc/message-length.c
> ===================================================================
> --- test/Misc/message-length.c (revision 84858)
> +++ test/Misc/message-length.c (working copy)
> @@ -29,4 +29,4 @@
>
>
>  // CHECK: FILE:23:78
> -// CHECK: {{^  ...// some long comment text and a brace, eh {} $}}
> +// CHECK: {{^  ...// some long comment text and a brace, eh {} .$}}
> I tried to match things with '\r' in it, but couldn't get it to work.
> Alternatively, we could mess with FileCheck, but I was afraid to.  It uses
> the MemoryBuffer function to read the file, so it's hard to chang the open
> mode there.
>
> -John
>
>   On Wed, Oct 21, 2009 at 12:58 PM, John Thompson <
> john.thompson.jtsoftware at gmail.com> wrote:
>
>> Nudge (1 of 3)
>>
>>
>> On Mon, Oct 19, 2009 at 8:56 AM, John Thompson <
>> john.thompson.jtsoftware at gmail.com> wrote:
>>
>>> Daniel,
>>>
>>> After updating, I noticed this test newly failing on Windows:
>>>
>>> 1>********************
>>> 1>FAIL: Clang::Misc/message-length.c (728 of 1688)
>>> 1>******************** TEST 'Clang::Misc/message-length.c' FAILED
>>> ********************
>>> 1>Script:
>>> 1>--
>>> 1>C:/Tools/llvm/bin/Debug\clang.EXE -fsyntax-only -fmessage-length=72
>>> C:\Tools\llvm\tools\clang\test\Misc\message-length.c 2>&1 | FileCheck
>>> -strict-whitespace C:\Tools\llvm\tools\clang\test\Misc\message-length.c
>>> 1>C:/Tools/llvm/bin/Debug\clang.EXE -fsyntax-only -fmessage-length=1
>>> C:\Tools\llvm\tools\clang\test\Misc\message-length.c
>>> 1>--
>>> 1>Exit Code: 1
>>> 1>Command Output (stdout):
>>> 1>--
>>> 1>Command 0: "C:/Tools/llvm/bin/Debug\clang.EXE" "-fsyntax-only"
>>> "-fmessage-length=72" "C:\Tools\llvm\tools\clang\test\Misc\message-length.c"
>>> 1>Command 0 Result: 0
>>> 1>Command 0 Output:
>>> 1>Command 0 Stderr:
>>> 1>Command 1: "FileCheck" "-strict-whitespace"
>>> "C:\Tools\llvm\tools\clang\test\Misc\message-length.c"
>>> 1>Command 1 Result: 1
>>> 1>Command 1 Output:
>>> 1>Command 1 Stderr:
>>> 1>C:\Tools\llvm\tools\clang\test\Misc\message-length.c:32:67: error:
>>> expected string not found in input
>>> 1>// CHECK: {{^  ...// some long comment text and a brace, eh {} $}}
>>> 1>                                                                  ^
>>> 1><stdin>:18:11: note: scanning from here
>>> 1>FILE:23:78: warning: expected 'ON' or 'OFF' or 'DEFAULT' in pragma
>>> 1>          ^
>>> 1>--
>>> 1>Command Output (stderr):
>>> 1>--
>>> 1>--
>>>
>>> -John
>>>
>>> --
>>> John Thompson
>>> John.Thompson.JTSoftware at gmail.com
>>>
>>>
>>
>>
>> --
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091023/7ac87d2d/attachment.html 

From spellegrini at dps.uibk.ac.at  Fri Oct 23 12:19:14 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Fri, 23 Oct 2009 19:19:14 +0200
Subject: [cfe-dev] Handling multiple translation units
Message-ID: <4AE1E592.2040209@dps.uibk.ac.at>

Dear all,
I need to perform code transformations based on inter-procedural 
analysis done on multiple translation units.

In order to do that I need to keep the AST generated for each 
translation unit in memory, do my analysis and then restart rewriting 
part of the AST I need to modify. Conceptually is not difficult my I am 
experiencing a weird behavior of Clang and maybe you can help me.

basically that's what I am doing:

vector<ASTContext*> ctxs;
for each input file{
     Preprocessor PP(...);
     InitializePreprocessor(PP);
     ctxs.push_back( new ASTContext(...., false, 0) );
     ParseAST(PP, *ctxs.back(),...);
}
// Now do ANALYSIS (e.g. building a clang::CallGraph )
for each context in ctxs{
     DeclContext *DC=ctxs[i];
     for each decl{
         if decl is a func{
             FuncDecl* FD = ();
             cout << FD->getNameAsString() << endl; <--- ERROR
         }
     }
}

As you can see from the code, every time I try to access the information 
of the ASTContext it looks like everything is gone. why?
I have to say that every time I parse a new translation unit I 
reinitialize the Preprocessor and I use different SourceManagers.

I also saw the possibility to use PHC files but I as I already told you 
I need to modify portion of the code and I am afraid PHC will not be 
suitable for me.

regards, Simone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091023/526ff6fe/attachment.html 

From dgregor at apple.com  Fri Oct 23 13:19:50 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Fri, 23 Oct 2009 11:19:50 -0700
Subject: [cfe-dev] Handling multiple translation units
In-Reply-To: <4AE1E592.2040209@dps.uibk.ac.at>
References: <4AE1E592.2040209@dps.uibk.ac.at>
Message-ID: <21FB4FA8-65AA-4834-B9C7-EED7302D5F66@apple.com>


On Oct 23, 2009, at 10:19 AM, Simone Pellegrini wrote:

> Dear all,
> I need to perform code transformations based on inter-procedural  
> analysis done on multiple translation units.
>
> In order to do that I need to keep the AST generated for each  
> translation unit in memory, do my analysis and then restart  
> rewriting part of the AST I need to modify. Conceptually is not  
> difficult my I am experiencing a weird behavior of Clang and maybe  
> you can help me.
>
> basically that's what I am doing:
>
> vector<ASTContext*> ctxs;
> for each input file{
>     Preprocessor PP(...);
>     InitializePreprocessor(PP);
>     ctxs.push_back( new ASTContext(...., false, 0) );
>     ParseAST(PP, *ctxs.back(),...);
> }

You will need to make sure that the SourceManager is also retained,  
since the ASTContext stores a reference to its SourceManager. The same  
is true for TargetInfo, IdentifierTable, SelectorTable, etc.

> // Now do ANALYSIS (e.g. building a clang::CallGraph )
> for each context in ctxs{
>     DeclContext *DC=ctxs[i];
>     for each decl{
>         if decl is a func{
>             FuncDecl* FD = ();
>             cout << FD->getNameAsString() << endl; <--- ERROR
>         }
>     }
> }
>
> As you can see from the code, every time I try to access the  
> information of the ASTContext it looks like everything is gone. why?


Well, getNameAsString() is going to try to look at an IdentifierInfo  
that may have been deallocated when the IdentifierTable is destroyed.  
Your best bet would be to keep the whole Preprocessor alive for each  
ASTContext.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091023/7300691a/attachment.html 

From john.thompson.jtsoftware at gmail.com  Fri Oct 23 13:39:43 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Fri, 23 Oct 2009 11:39:43 -0700
Subject: [cfe-dev] CIndex changes
Message-ID: <aad8390910231139v27e295fw3e1e4db9ea1f6cd0@mail.gmail.com>

Ted/Steve,

Do you want me to check in my changes for DLL-izing CIndex?

I'd like to do so, because Index.h always conflicts when I update.
Here's a patch against the latest, with just the changes for getting the DLL
to build.

It would be nice if you could fix the string problem too, so the test
doesn't fail on Windows.

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091023/478f720c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cindex.patch
Type: application/octet-stream
Size: 8263 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091023/478f720c/attachment.obj 

From dgregor at apple.com  Fri Oct 23 13:53:51 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Fri, 23 Oct 2009 11:53:51 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <aad8390910231148m7e18191cs98f27819adfbe12f@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
	<6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>
	<A4D41316-AA5C-4C13-9647-749A19DC0BD7@apple.com>
	<aad8390910231148m7e18191cs98f27819adfbe12f@mail.gmail.com>
Message-ID: <739D813D-ABAC-47CB-9A1B-CF6EA083A030@apple.com>


On Oct 23, 2009, at 11:48 AM, John Thompson wrote:

> That (__has_include etc.) sounds good.  I'm assuming that is for use  
> in a #if?

Yes, just like __has_builtin and __has_feature.

It probably makes sense to allow the same forms as include directives,  
e.g.,

	__has_include(<stdlib.h>)
	__has_include("stdlib.h")
	__has_include_next(<stdlib.h>)
	__has_include_next("stdlib.h")


> Would you like me to take a stab at it>

That would be great!

	- Doug

> -John
> On Fri, Oct 23, 2009 at 9:33 AM, Douglas Gregor <dgregor at apple.com>  
> wrote:
>
> On Oct 23, 2009, at 9:10 AM, Daniel Dunbar wrote:
>
> On Thu, Oct 15, 2009 at 5:23 PM, Douglas Gregor <dgregor at apple.com>  
> wrote:
> Also, could someone look at the enclosed patch for stdint.h?  This  
> also
> fixes some failing tests, since VC++ doesn't have stdint.h.  Who is  
> point on
> this?
>
> I'm not thrilled about using _M_IX86 and _M_X64 to detect what is  
> really a
> library issue. I guess in the worst case we could have a configure- 
> time
> check that determines whether we can #include_next <stdint.h>, but
> that's.... horrible.
> Unless someone has a better idea... ?
>
> No configure-time check. :P
>
> We could always invent a clang specific internal define for this,
> which targets can set in their predefines. For example,
> __STDC_INCLUDES_STDINT__ or so.
>
>
> It seems to me that target information should be limited to  
> information about the ABI, linker, assembler, and other parts of the  
> toolchain, but not the (C or C++) standard library, since standard  
> libraries are meant to be interchangeable.
>
> However, I have an idea. Clang's <stdint.h> looks like this:
>
> /* If we're hosted, fall back to the system's stdint.h, which might  
> have
>  * additional definitions.
>  */
> #if __STDC_HOSTED__
> # include_next <stdint.h>
> #else
> // our own definitions of <stdint.h>
> #endif
>
> why not add new __has_include and __has_include_next preprocessor  
> primitives, so that we can *really* detect whether we have a system  
> <stdint.h>?
>
> This also gets us closer to eliminating the need for configure :D
>
>        - Doug
>
>
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091023/1b84001b/attachment-0001.html 

From daniel at zuster.org  Sat Oct 24 15:41:55 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 24 Oct 2009 13:41:55 -0700
Subject: [cfe-dev] Need Python help in TestRunner.py
In-Reply-To: <aad8390910130719r12729ca7m1519d581d04541ef@mail.gmail.com>
References: <aad8390910130719r12729ca7m1519d581d04541ef@mail.gmail.com>
Message-ID: <6a8523d60910241341j256fe442l20d610a85a258b43@mail.gmail.com>

On Tue, Oct 13, 2009 at 7:19 AM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> In running the test Driver/ast.c on Windows:
>
> 2>? File "C:\Tools\llvm\utils\lit\TestRunner.py", line 79, in executeShCmd
> 2>??? raise NotImplementedError,"Unsupported redirect: %r" % (r,)
> 2>NotImplementedError: Unsupported redirect: (('>>',),
> 'C:\\Tools\\llvm\\tools\\clang\\test\\Driver\\Output\\ast.c.tmp')
> It appears that '>>' is not one of the conditions in the if/else series, and
> I don't know Python well enough to fix it.
>
> My guess of adding:
>
> ??????????? elif r[0] == ('>>',):
> ??????????????? redirects[1] = [r[1], 'a', None]

Looks like this should work, to me. I checked it on Darwin using
internal-execution of the test scripts and checked it in. Let me know
if it seems not to work on Windows.

 - Daniel

> resulted in the redirected output being put at the front of the output file.
> So if this is a quick fix for someone, I'd appreciate the help.
>
> -John
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


From daniel at zuster.org  Sat Oct 24 15:49:17 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 24 Oct 2009 13:49:17 -0700
Subject: [cfe-dev] Need Python help in TestRunner.py
In-Reply-To: <aad8390910151509h2767e3e5k1ab3e01f9256ede7@mail.gmail.com>
References: <aad8390910130719r12729ca7m1519d581d04541ef@mail.gmail.com>
	<6a8523d60910130751t41c3f6c0qbe43dd1eb1390fe1@mail.gmail.com>
	<aad8390910151509h2767e3e5k1ab3e01f9256ede7@mail.gmail.com>
Message-ID: <6a8523d60910241349k553dc8f7s68e665d9a4e23ff8@mail.gmail.com>

Hi John,

On Thu, Oct 15, 2009 at 3:09 PM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> Daniel,
>
> Here's a wierd one regarding running the test/Frontend/ast-main.c test?on
> Windows.? The "diff" utility seems to be crashing when run from the test
> scripts in .? Running the same command line from the command shell doesn't
> crash:
>
> diff C:\Tools\llvm\tools\clang\test\Frontend\Output\ast-main.c.tmp1.ll
> C:\Tools\llvm\tools\clang\test\Frontend\Output\ast-main.c.tmp2.ll
>
> By default, on my system,?I'm using the diff from the gnuwin32 utils.? I
> also substituted the msys diff, but it crashes also, but only when run under
> the test scripts.
> Are you seeing this too?

Nope, I've never seen diff crashing.

> Any thoughts?

No clue. :)

One major difference about stuff run under the test script is it tries
to limit the things that are in the environment. Maybe that makes your
diff unhappy somehow?

 - Daniel

> -John
>
> On Tue, Oct 13, 2009 at 7:51 AM, Daniel Dunbar <daniel at zuster.org> wrote:
>>
>> Hey John,
>>
>> I'll try to take a look at this soon. File a bug or email me if I seem
>> to forget. :)
>>
>> ?- Daniel
>>
>> On Tue, Oct 13, 2009 at 5:19 PM, John Thompson
>> <john.thompson.jtsoftware at gmail.com> wrote:
>> > In running the test Driver/ast.c on Windows:
>> >
>> > 2>? File "C:\Tools\llvm\utils\lit\TestRunner.py", line 79, in
>> > executeShCmd
>> > 2>??? raise NotImplementedError,"Unsupported redirect: %r" % (r,)
>> > 2>NotImplementedError: Unsupported redirect: (('>>',),
>> > 'C:\\Tools\\llvm\\tools\\clang\\test\\Driver\\Output\\ast.c.tmp')
>> > It appears that '>>' is not one of the conditions in the if/else series,
>> > and
>> > I don't know Python well enough to fix it.
>> >
>> > My guess of adding:
>> >
>> > ??????????? elif r[0] == ('>>',):
>> > ??????????????? redirects[1] = [r[1], 'a', None]
>> > resulted in the redirected output being put at the front of the output
>> > file.
>> > So if this is a quick fix for someone, I'd appreciate the help.
>> >
>> > -John
>> > --
>> > John Thompson
>> > John.Thompson.JTSoftware at gmail.com
>> >
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >
>> >
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


From rengolin at systemcall.org  Sat Oct 24 16:03:48 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sat, 24 Oct 2009 22:03:48 +0100
Subject: [cfe-dev] x86_64 with -emit-llvm
Message-ID: <d9b9d95f0910241403h2782d006g3aff9e96b9a5fd5a@mail.gmail.com>

Hi all,

A few newbie questions...

What am I missing here?

$ clang -emit-llvm anyfile.c
clang: error: 'x86_64-unknown-linux-gnu': unable to pass LLVM bit-code
files to linker

Linux 2.6.31-14 x86_64
llvm/clang from svn-head

-emit-ast works, but it's binary, how can I read it?

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From srp at srparish.net  Sat Oct 24 17:22:10 2009
From: srp at srparish.net (Scott R Parish)
Date: Sat, 24 Oct 2009 17:22:10 -0500 (CDT)
Subject: [cfe-dev] bug? comparison of distinct pointer types ('void *' and
	'void *')
Message-ID: <1256422930.v2.mailanyonewebmail-240137@fuse50>

Doing "ptr == 0" seems to work fine, but doing "ptr == (void *)0" (which
NULL expands to on my platform) doesn't. This is using the just release
llvm+clang linux 64bit binary version of clang.

[0]/tmp$ cat /tmp/ptrcmp.c
#include <stdio.h>

int
is_null(void *ptr)
{
        return ptr == NULL;
}
[0]/tmp$ clang -o /tmp/ptrcmp.o -c /tmp/ptrcmp.c
/tmp/ptrcmp.c:6:13: warning: comparison of distinct pointer types
      ('void *' and 'void *')
        return ptr == NULL;
               ~~~ ^  ~~~~
1 diagnostic generated.
[0]/tmp$



From srp at srparish.net  Sat Oct 24 22:55:52 2009
From: srp at srparish.net (Scott R Parish)
Date: Sat, 24 Oct 2009 22:55:52 -0500 (CDT)
Subject: [cfe-dev] bug? comparison of distinct pointer types ('void *'
 and 'void *')
Message-ID: <1256442952.v2.mailanyonewebmail-240137@fuse49>

Sorry, user error (red-faced); didn't realize i still had an old copy of
clang sitting earlier in my PATH.

sRp


From spellegrini at dps.uibk.ac.at  Sun Oct 25 04:44:22 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Sun, 25 Oct 2009 10:44:22 +0100
Subject: [cfe-dev] Handling multiple translation units
In-Reply-To: <21FB4FA8-65AA-4834-B9C7-EED7302D5F66@apple.com>
References: <4AE1E592.2040209@dps.uibk.ac.at>
	<21FB4FA8-65AA-4834-B9C7-EED7302D5F66@apple.com>
Message-ID: <4AE41DF6.9010303@dps.uibk.ac.at>

Douglas Gregor wrote:
>
> On Oct 23, 2009, at 10:19 AM, Simone Pellegrini wrote:
>
>> Dear all,
>> I need to perform code transformations based on inter-procedural 
>> analysis done on multiple translation units.
>>
>> In order to do that I need to keep the AST generated for each 
>> translation unit in memory, do my analysis and then restart rewriting 
>> part of the AST I need to modify. Conceptually is not difficult my I 
>> am experiencing a weird behavior of Clang and maybe you can help me.
>>
>> basically that's what I am doing:
>>
>> vector<ASTContext*> ctxs;
>> for each input file{
>>     Preprocessor PP(...);
>>     InitializePreprocessor(PP);
>>     ctxs.push_back( new ASTContext(...., false, 0) );
>>     ParseAST(PP, *ctxs.back(),...);
>> }
>
> You will need to make sure that the SourceManager is also retained, 
> since the ASTContext stores a reference to its SourceManager. The same 
> is true for TargetInfo, IdentifierTable, SelectorTable, etc.
>
>> // Now do ANALYSIS (e.g. building a clang::CallGraph )
>> for each context in ctxs{
>>     DeclContext *DC=ctxs[i];
>>     for each decl{
>>         if decl is a func{
>>             FuncDecl* FD = ();
>>             cout << FD->getNameAsString() << endl; <--- ERROR
>>         }
>>     }
>> }
>>    
>> As you can see from the code, every time I try to access the 
>> information of the ASTContext it looks like everything is gone. why?
>
> Well, getNameAsString() is going to try to look at an IdentifierInfo 
> that may have been deallocated when the IdentifierTable is destroyed. 
> Your best bet would be to keep the whole Preprocessor alive for each 
> ASTContext.
Thanks Doug,
it works as expected now... no more strange error messages because of 
corrupted memory!
cheers bye
>
> - Doug


From spellegrini at dps.uibk.ac.at  Sun Oct 25 08:24:52 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Sun, 25 Oct 2009 14:24:52 +0100
Subject: [cfe-dev] CallGraph and TranslationUnits
Message-ID: <4AE451A4.8020700@dps.uibk.ac.at>

Dear all,
the clang::CallGraph class allows to build call graphs, by using the 
method addTU(ASTUnit&), starting from clang::ASTUnit object which (as 
far as I understand from the API) are normally generated from PCH files .
However, someone ( like me for example :) ) would like to build 
CallGraphs starting from instances of clang::idx::TranslationUnit class 
and the current API doesn't allow that. :(

If you look to the implementation of the addTU(ASTUnit&) method there is 
no reason why it couldn't be possible to built a CallGraph starting from 
a TranslationUnit object. What the method does is looking for the 
ASTContext, and TranslationUnit objects have the same getASTContext() 
method.

I think there is a little bit of confusion about the API. Right now it 
seems to be that there are two kinds of TranslationUnits (1 coming from 
PCH files and another used by the Indexer for indexing entities) and 
there is no homogeneous way to handle this 2 objects as they have no 
common ancestors. Why the getASTContext() method both in ASTUnit and 
TranslationUnit is not factorized into an interface? this will make 
CallGraph.addTU() more generic. Or, if possible, having ASTUnit 
implementing the TranslationUnit interface (I don't know whether there 
is any conceptual reason that prevent ASTUnit to be a TranslationUnit).

For the moment I was able to solve the problem by slightly changing the 
CallGraph interface by introducing the add(clang::ids::TranslationUnit&) 
method and by factorizing the implementations with a call to a private 
method addAST(ASTContext&). I think things will be even easier if the 
CallGraph is built starting from ASTContext.

Am I missing something?

regards, Simone P.



From clattner at apple.com  Sun Oct 25 13:14:48 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 25 Oct 2009 11:14:48 -0700
Subject: [cfe-dev] 'Skip' argument to Sema::GetTypeForDeclarator
Message-ID: <20551162-ACBB-4738-BA97-A7D987EC664D@apple.com>

Hi Sebastian,

I see you added the Skip argument to Sema::GetTypeForDeclarator, and  
that it is only used when processing new[] expressions.  Can you  
please eliminate this by making ActOnCXXNew remove the DeclaratorChunk  
from the Declarator if appropriate?  I'd prefer to keep  
GetTypeForDeclarator as simple as possible, and this approach would  
isolate the complexity in the one place that needs it.

Thanks,

-Chris

From daniel at zuster.org  Sun Oct 25 15:29:23 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 25 Oct 2009 13:29:23 -0700
Subject: [cfe-dev] message-length.c
In-Reply-To: <aad8390910230932i4e8b6cd1y414e47f9801d95c9@mail.gmail.com>
References: <aad8390910190856o7b1ec5c4m3d45952a63a3df30@mail.gmail.com>
	<aad8390910211258m2ea84dbbr98ad50dbbca4f95f@mail.gmail.com>
	<aad8390910230932i4e8b6cd1y414e47f9801d95c9@mail.gmail.com>
Message-ID: <6a8523d60910251329i3755bc82t2d6be0e8bc91efc7@mail.gmail.com>

Hi John,

I think we should probably fix this issue in FileCheck somehow, but
for now I'll tweak the test to work around the issue.

 - Daniel

On Fri, Oct 23, 2009 at 9:32 AM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> Daniel,
>
> I did some playing around with message-length.c, and I think the '\r''s are
> confusing FileCheck.? I think it's the regex function, which is seeing them,
> because the file is opened in binary mode.
> This seems to be the easy fix:
>
> Index: test/Misc/message-length.c
> ===================================================================
> --- test/Misc/message-length.c?(revision 84858)
> +++ test/Misc/message-length.c?(working copy)
> @@ -29,4 +29,4 @@
>
>
> ?// CHECK: FILE:23:78
> -// CHECK: {{^? ...// some long comment text and a brace, eh {} $}}
> +// CHECK: {{^? ...// some long comment text and a brace, eh {} .$}}
> I tried to match things with '\r' in it, but couldn't get it to work.
> Alternatively, we could mess?with FileCheck, but I was afraid to.? It?uses
> the MemoryBuffer function to read the file, so it's hard to chang the open
> mode there.
>
> -John
>
> On Wed, Oct 21, 2009 at 12:58 PM, John Thompson
> <john.thompson.jtsoftware at gmail.com> wrote:
>>
>> Nudge (1 of 3)
>>
>> On Mon, Oct 19, 2009 at 8:56 AM, John Thompson
>> <john.thompson.jtsoftware at gmail.com> wrote:
>>>
>>> Daniel,
>>>
>>> After updating, I noticed this test newly failing on Windows:
>>>
>>> 1>********************
>>> 1>FAIL: Clang::Misc/message-length.c (728 of 1688)
>>> 1>******************** TEST 'Clang::Misc/message-length.c' FAILED
>>> ********************
>>> 1>Script:
>>> 1>--
>>> 1>C:/Tools/llvm/bin/Debug\clang.EXE -fsyntax-only -fmessage-length=72
>>> C:\Tools\llvm\tools\clang\test\Misc\message-length.c 2>&1 | FileCheck
>>> -strict-whitespace C:\Tools\llvm\tools\clang\test\Misc\message-length.c
>>> 1>C:/Tools/llvm/bin/Debug\clang.EXE -fsyntax-only -fmessage-length=1
>>> C:\Tools\llvm\tools\clang\test\Misc\message-length.c
>>> 1>--
>>> 1>Exit Code: 1
>>> 1>Command Output (stdout):
>>> 1>--
>>> 1>Command 0: "C:/Tools/llvm/bin/Debug\clang.EXE" "-fsyntax-only"
>>> "-fmessage-length=72" "C:\Tools\llvm\tools\clang\test\Misc\message-length.c"
>>> 1>Command 0 Result: 0
>>> 1>Command 0 Output:
>>> 1>Command 0 Stderr:
>>> 1>Command 1: "FileCheck" "-strict-whitespace"
>>> "C:\Tools\llvm\tools\clang\test\Misc\message-length.c"
>>> 1>Command 1 Result: 1
>>> 1>Command 1 Output:
>>> 1>Command 1 Stderr:
>>> 1>C:\Tools\llvm\tools\clang\test\Misc\message-length.c:32:67: error:
>>> expected string not found in input
>>> 1>// CHECK: {{^? ...// some long comment text and a brace, eh {} $}}
>>> 1>????????????????????????????????????????????????????????????????? ^
>>> 1><stdin>:18:11: note: scanning from here
>>> 1>FILE:23:78: warning: expected 'ON' or 'OFF' or 'DEFAULT' in pragma
>>> 1>????????? ^
>>> 1>--
>>> 1>Command Output (stderr):
>>> 1>--
>>> 1>--
>>>
>>> -John
>>>
>>> --
>>> John Thompson
>>> John.Thompson.JTSoftware at gmail.com
>>>
>>
>>
>>
>> --
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>
>
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


From daniel at zuster.org  Sun Oct 25 15:44:29 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 25 Oct 2009 13:44:29 -0700
Subject: [cfe-dev] XFAIL and XTARGET
In-Reply-To: <aad8390910211926h5f0e9a3dl616ec23520916774@mail.gmail.com>
References: <aad8390910211926h5f0e9a3dl616ec23520916774@mail.gmail.com>
Message-ID: <6a8523d60910251344n144812fj126a674db0119065@mail.gmail.com>

On Wed, Oct 21, 2009 at 7:26 PM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> How are XFAIL and XTARGET supposed to work in a test?

For Clang they behave differently than for LLVM, this is a historical
wart. It's on my list to move Clang to the same model that LLVM uses.

> It would be nice if these were documented on the Testing Infrustructure
> page.

Yes, yes it would.

> In looking at the TestRunner.py file, it seems that you should be able to
> put something this this in a test to tell it that the test is expected to
> fail on Windows:
>
> // XFAIL: i686-pc-win32,x86_64-pc-win32
>
> But it seems that regardless of what I put after XFAIL, the test comes out
> as an expected failure if the test fails, or an unexpected pass if the test
> passes.? I've been bouncing between Linux and Windows trying different
> things.? It seems that only "// XFAIL" is currently used.

Right, Clang just looks for XFAIL and doesn't have any support for
failing on a particular target, or failing on all except a particular
target.

> I don't know Python enough to really understand what should be happening.
>
> Basically, the Driver/hello.c test?doesn't pass on Windows.? I though if I
> put MinGW gcc in the PATH it might pass, but I get the following errors from
> just running the compile command line:
>
> C:\Tools\llvm\tools\clang\test>clang -ccc-echo -v -o tmp.o Driver/hello.c
> clang version 1.1 (trunk 84674)
> Target: i686-pc-win32
> Thread model: posix
> ?"C:/Tools/llvm/bin/Debug/clang-cc.exe" -triple i686-pc-win32 -S
> -disable-free -main-file-name hello.c --relocation-model static --disable-f
> p-elim --unwind-tables=0 --fmath-errno=1 -v -fexceptions=0
> -fdiagnostics-show-option -o C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s
> -x c D
> river/hello.c
> clang-cc version 1.1 based upon llvm 2.7svn hosted on i686-pc-win32
> ignoring nonexistent directory "c:\Program Files\Microsoft Visual Studio
> 9.0\VC\PlatformSDK\Include"
> ignoring nonexistent directory "/usr/local/include"
> ignoring nonexistent directory "/System/Library/Frameworks"
> ignoring nonexistent directory "/Library/Frameworks"
> #include "..." search starts here:
> #include <...> search starts here:
> ?C:/Tools/llvm/bin/lib/clang/1.1/include
> ?c:\Program Files\Microsoft Visual Studio 9.0\VC\include
> ?/usr/include
> End of search list.
> ?"c:/mingw/bin/gcc.exe" -v -c -o
> C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000001.o -x assembler
> C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s
> Using built-in specs.
> Target: mingw32
> Configured with: ../gcc-4.4.0/configure
> --enable-languages=c,ada,c++,fortran,java,objc,obj-c++
> --disable-sjlj-exceptions --enable-shared --e
> nable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry
> --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefi
> x=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root
> --build=mingw32
> Thread model: win32
> gcc version 4.4.0 (GCC)
> COLLECT_GCC_OPTIONS='-v' '-c' '-o'
> 'C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000001.o' '-mtune=i386'
> ?c:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/as.exe -o
> C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000001.o C:/DOCUME~1/fcadmin/L
> OCALS~1/Temp/cc-000000.s
> C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s: Assembler messages:
> C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s:4: Error: no such instruction:
> `align 16'
> C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s:20: Error: no such
> instruction: `align 16'
> C:/DOCUME~1/fcadmin/LOCALS~1/Temp/cc-000000.s:22: Error: no such
> instruction: `db "I'm a little driver, short and stout.\000"'
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)

Dunno, what's going on here.

By the way, I would recommend filing some these things as bugzillas
instead of just emailing them to cfe-dev, its makes them easier to
track over time and makes sure they don't get lost.

 - Daniel


From daniel at zuster.org  Sun Oct 25 15:56:01 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 25 Oct 2009 13:56:01 -0700
Subject: [cfe-dev] x86_64 with -emit-llvm
In-Reply-To: <d9b9d95f0910241403h2782d006g3aff9e96b9a5fd5a@mail.gmail.com>
References: <d9b9d95f0910241403h2782d006g3aff9e96b9a5fd5a@mail.gmail.com>
Message-ID: <6a8523d60910251356k69219924u36db3eaa1d3ab777@mail.gmail.com>

On Sat, Oct 24, 2009 at 2:03 PM, Renato Golin <rengolin at systemcall.org> wrote:
> Hi all,
>
> A few newbie questions...
>
> What am I missing here?
>
> $ clang -emit-llvm anyfile.c
> clang: error: 'x86_64-unknown-linux-gnu': unable to pass LLVM bit-code
> files to linker

Use 'clang -c -emit-llvm anyfile.c', this will give you an LLVM
bitcode file as anyfile.o.

 - Daniel

From rengolin at systemcall.org  Sun Oct 25 16:18:55 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sun, 25 Oct 2009 21:18:55 +0000
Subject: [cfe-dev] x86_64 with -emit-llvm
In-Reply-To: <6a8523d60910251356k69219924u36db3eaa1d3ab777@mail.gmail.com>
References: <d9b9d95f0910241403h2782d006g3aff9e96b9a5fd5a@mail.gmail.com>
	<6a8523d60910251356k69219924u36db3eaa1d3ab777@mail.gmail.com>
Message-ID: <d9b9d95f0910251418k3a07b687rcf333f69f0b3bd20@mail.gmail.com>

2009/10/25 Daniel Dunbar <daniel at zuster.org>:
> Use 'clang -c -emit-llvm anyfile.c', this will give you an LLVM
> bitcode file as anyfile.o.

Thanks Daniel, it worked.

$ clang -c foo.c -o - -emit-llvm | llvm-dis -o=- | less

How can I read the AST file generated by the -emit-ast ?

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From daniel at zuster.org  Sun Oct 25 16:31:58 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 25 Oct 2009 14:31:58 -0700
Subject: [cfe-dev] Cross-compiling with clang
In-Reply-To: <31014a580910120239s134f9602rb6e036cd285ec28e@mail.gmail.com>
References: <31014a580910022014p7dda3b8eyf80b051468fea77c@mail.gmail.com>
	<5BF49EAE-035B-48D6-9488-F71981D09477@apple.com>
	<31014a580910120239s134f9602rb6e036cd285ec28e@mail.gmail.com>
Message-ID: <6a8523d60910251431u366de40ao75ef52442ed1cfe7@mail.gmail.com>

Hi Mark,

On Mon, Oct 12, 2009 at 2:39 AM, Mark A. Miller <mark at mirell.org> wrote:
> On Sat, Oct 3, 2009 at 1:28 AM, Chris Lattner <clattner at apple.com> wrote:
>> On Oct 2, 2009, at 8:14 PM, Mark A. Miller wrote:
>>
>> As a preface, I am not a compiler developer, so please take my questions
>> with a grain of salt. But there doesn't appear to be a clang-user mailing
>> list, so I'm posting to -dev.
>> I'm extremely interested in clang, since it both attempts to be saner than
>> what gcc has become, and doesn't have the community forking licensing issues
>> of GPLv2 and GPLv3. My recent projects have involved building
>> cross-compilers for various targets, such as ARM, MIPS, PPC, sh4, et cetera.
>> My main question is, has any work been done on allowing clang to
>> cross-compile various targets? I found the following
>> bug:?http://llvm.org/bugs/show_bug.cgi?id=4127 which indicated that it was
>> still a work in progress.
>> Also, I suppose this question may be better posed to the llvm list, but is
>> there any documentation on how to use a gcc frontend and llvm backend to
>> cross-compile?
>> Lastly, and this is more of a slight nitpick issue, since I managed to find
>> the bug with the following mailing list
>> post:?http://article.gmane.org/gmane.comp.compilers.clang.devel/5893 I'd
>> point out that the -arch feature currently only works on MacOSX. I wasted
>> several hours trying to figure out what I was doing wrong on my Linux
>> installation until I found ths out.
>>
>> Hi Mark,
>> This is an area that we are actively interested in involving, but no one is
>> driving yet. ?Are you interested in helping out? ?I'm not too familiar with
>> the issues and Daniel (who is most knowledgeable about the driver) is out on
>> vacation for 2 weeks.
>> -Chris
>
> Sorry for the late reply.
>
> I'd be interested in helping in any capability I can.
>
> I was mainly curious as to the current status of cross-compiling
> aspect of clang, since I'm eager for it to supplant GPLv3ed gcc.

The current status is basically what you've observed. We would like it
to happen, but no one is currently actively working on it.

 - Daniel


From anton at korobeynikov.info  Sun Oct 25 16:49:59 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 26 Oct 2009 01:49:59 +0400
Subject: [cfe-dev] Cross-compiling with clang
In-Reply-To: <6a8523d60910251431u366de40ao75ef52442ed1cfe7@mail.gmail.com>
References: <31014a580910022014p7dda3b8eyf80b051468fea77c@mail.gmail.com>
	<5BF49EAE-035B-48D6-9488-F71981D09477@apple.com>
	<31014a580910120239s134f9602rb6e036cd285ec28e@mail.gmail.com>
	<6a8523d60910251431u366de40ao75ef52442ed1cfe7@mail.gmail.com>
Message-ID: <b087fca00910251449y2800e9b7p8871d4599cf47b03@mail.gmail.com>

Hi, Daniel

> The current status is basically what you've observed. We would like it
> to happen, but no one is currently actively working on it.
That's not true and you know it :)

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From clattner at apple.com  Sun Oct 25 17:51:04 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 25 Oct 2009 15:51:04 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <739D813D-ABAC-47CB-9A1B-CF6EA083A030@apple.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
	<6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>
	<A4D41316-AA5C-4C13-9647-749A19DC0BD7@apple.com>
	<aad8390910231148m7e18191cs98f27819adfbe12f@mail.gmail.com>
	<739D813D-ABAC-47CB-9A1B-CF6EA083A030@apple.com>
Message-ID: <066A0998-FCD5-42EF-AF7D-8ED04CE022EC@apple.com>

On Oct 23, 2009, at 11:53 AM, Douglas Gregor wrote:
> On Oct 23, 2009, at 11:48 AM, John Thompson wrote:
>
>> That (__has_include etc.) sounds good.  I'm assuming that is for  
>> use in a #if?
>
> Yes, just like __has_builtin and __has_feature.
>
> It probably makes sense to allow the same forms as include  
> directives, e.g.,
>
> 	__has_include(<stdlib.h>)
> 	__has_include("stdlib.h")
> 	__has_include_next(<stdlib.h>)
> 	__has_include_next("stdlib.h")

This would be really really really cool.  I'd start with the plain  
quoted version, we can deal with the angled string later, but it will  
be trickier.

-Chris


From daniel at zuster.org  Sun Oct 25 18:15:40 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 25 Oct 2009 16:15:40 -0700
Subject: [cfe-dev] x86_64 with -emit-llvm
In-Reply-To: <d9b9d95f0910251418k3a07b687rcf333f69f0b3bd20@mail.gmail.com>
References: <d9b9d95f0910241403h2782d006g3aff9e96b9a5fd5a@mail.gmail.com>
	<6a8523d60910251356k69219924u36db3eaa1d3ab777@mail.gmail.com>
	<d9b9d95f0910251418k3a07b687rcf333f69f0b3bd20@mail.gmail.com>
Message-ID: <6a8523d60910251615s75c1f093s5e8be8e94e680275@mail.gmail.com>

On Sun, Oct 25, 2009 at 2:18 PM, Renato Golin <rengolin at systemcall.org> wrote:
> 2009/10/25 Daniel Dunbar <daniel at zuster.org>:
>> Use 'clang -c -emit-llvm anyfile.c', this will give you an LLVM
>> bitcode file as anyfile.o.
>
> Thanks Daniel, it worked.
>
> $ clang -c foo.c -o - -emit-llvm | llvm-dis -o=- | less
>
> How can I read the AST file generated by the -emit-ast ?

To do what? It's a binary file meant to be read by clang, nothing else.

 - Daniel

From rengolin at systemcall.org  Sun Oct 25 18:40:33 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sun, 25 Oct 2009 23:40:33 +0000
Subject: [cfe-dev] x86_64 with -emit-llvm
In-Reply-To: <6a8523d60910251615s75c1f093s5e8be8e94e680275@mail.gmail.com>
References: <d9b9d95f0910241403h2782d006g3aff9e96b9a5fd5a@mail.gmail.com>
	<6a8523d60910251356k69219924u36db3eaa1d3ab777@mail.gmail.com>
	<d9b9d95f0910251418k3a07b687rcf333f69f0b3bd20@mail.gmail.com>
	<6a8523d60910251615s75c1f093s5e8be8e94e680275@mail.gmail.com>
Message-ID: <d9b9d95f0910251640l7f477314s342f5b468469049@mail.gmail.com>

2009/10/25 Daniel Dunbar <daniel at zuster.org>:
> To do what? It's a binary file meant to be read by clang, nothing else.

I was hoping I could use it to debug modifications on clang regarding
AST changes in a more old-fashioned way.

Nevermind, thank you.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From xuzhongxing at gmail.com  Sun Oct 25 20:37:56 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Mon, 26 Oct 2009 09:37:56 +0800
Subject: [cfe-dev] CallGraph and TranslationUnits
In-Reply-To: <4AE451A4.8020700@dps.uibk.ac.at>
References: <4AE451A4.8020700@dps.uibk.ac.at>
Message-ID: <5400aeb80910251837n1562a70dx91342e4cbfee79fc@mail.gmail.com>

Hi Simone,

I wrote the current implementation of callgraph months ago as an
experimentation. It's not meant to be a stable interface. If you have
more general interface or better implementation, patches are welcome.

- Zhongxing Xu

2009/10/25 Simone Pellegrini <spellegrini at dps.uibk.ac.at>:
> Dear all,
> the clang::CallGraph class allows to build call graphs, by using the
> method addTU(ASTUnit&), starting from clang::ASTUnit object which (as
> far as I understand from the API) are normally generated from PCH files .
> However, someone ( like me for example :) ) would like to build
> CallGraphs starting from instances of clang::idx::TranslationUnit class
> and the current API doesn't allow that. :(
>
> If you look to the implementation of the addTU(ASTUnit&) method there is
> no reason why it couldn't be possible to built a CallGraph starting from
> a TranslationUnit object. What the method does is looking for the
> ASTContext, and TranslationUnit objects have the same getASTContext()
> method.
>
> I think there is a little bit of confusion about the API. Right now it
> seems to be that there are two kinds of TranslationUnits (1 coming from
> PCH files and another used by the Indexer for indexing entities) and
> there is no homogeneous way to handle this 2 objects as they have no
> common ancestors. Why the getASTContext() method both in ASTUnit and
> TranslationUnit is not factorized into an interface? this will make
> CallGraph.addTU() more generic. Or, if possible, having ASTUnit
> implementing the TranslationUnit interface (I don't know whether there
> is any conceptual reason that prevent ASTUnit to be a TranslationUnit).
>
> For the moment I was able to solve the problem by slightly changing the
> CallGraph interface by introducing the add(clang::ids::TranslationUnit&)
> method and by factorizing the implementations with a call to a private
> method addAST(ASTContext&). I think things will be even easier if the
> CallGraph is built starting from ASTContext.
>
> Am I missing something?
>
> regards, Simone P.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

From dgregor at apple.com  Mon Oct 26 18:13:49 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 26 Oct 2009 16:13:49 -0700
Subject: [cfe-dev] Building Wine with clang on Mac OS X 10.6
In-Reply-To: <4ADC9229.2080900@mymail.mines.edu>
References: <4ADC7920.40309@mymail.mines.edu> <4ADC79F3.7050602@gmail.com>
	<4ADC86AD.1070503@mymail.mines.edu>
	<ACD46929-2653-4C75-B32B-E6D3F46647E0@apple.com>
	<4ADC9229.2080900@mymail.mines.edu>
Message-ID: <1A36AAB4-77CD-489F-9DDF-D48963C37985@apple.com>


On Oct 19, 2009, at 9:22 AM, Charles Davis wrote:

> Douglas Gregor wrote:
>>
>> On Oct 19, 2009, at 8:33 AM, Charles Davis wrote:
>>> As I said earlier (in an email some of you may not have gotten, I  
>>> got a
>>> bunch of warning diagnostics about
>>> __attribute__((__force_align_arg_pointer__)), which, according to a
>>> comment in include/windef.h, is supposed to ensure the stack remains
>>> 16-byte aligned. Is this needed under clang for __stdcall  
>>> functions on
>>> Mac OS X? It's apparently needed under gcc.
>>
>> We don't have support for this attribute in Clang, and I don't know
>> whether it is necessary for what you're doing. Please file an  
>> extension
>> request at
>>
>>    http://llvm.org/bugs/
> You don't? Well then, I guess, to be on the safe side, I should file a
> request.

Thanks, I see it at http://llvm.org/bugs/show_bug.cgi?id=5254

>>> Speaking of __stdcall, I got some diagnostics related to
>>> __attribute__((__stdcall__)) being used on function pointers. gcc  
>>> does
>>> not complain about this. Is this a known issue?
>>
>> Not one I know about. What diagnostics on what code?
> Basically, any code that defines a __stdcall function pointer typedef,
> like this one for example:
>
> ../../include/winnt.h:5034:15: warning: '__stdcall__' attribute only
> applies to
> function types
> typedef VOID (NTAPI * PFLS_CALLBACK_FUNCTION) ( PVOID );
>              ^
> ../../include/winnt.h:44:15: note: instantiated from:
> #define NTAPI __stdcall
>              ^../../include/windef.h:57:38: note: instantiated from:
> #    define __stdcall __attribute__((__stdcall__))
> __attribute__((__force_align_
> arg_pointer__))                                     ^


This boils down to, e.g.,

	typedef void (__attribute__((stdcall)) * callback)(int, int);

which we complain about:

stdcall.c:1:30: warning: 'stdcall' attribute only applies to function  
types
typedef void (__attribute__((stdcall)) * callback)(int, int);
                              ^

Basically, we don't yet have a way to encode the stdcall attribute in  
the type system, so we can't form a function pointer to a stdcall  
function. I've filed a PR for this, here:

	http://llvm.org/bugs/show_bug.cgi?id=5310

	- Doug

From cdavis at mymail.mines.edu  Mon Oct 26 18:28:40 2009
From: cdavis at mymail.mines.edu (Charles Davis)
Date: Mon, 26 Oct 2009 17:28:40 -0600
Subject: [cfe-dev] Building Wine with clang on Mac OS X 10.6
In-Reply-To: <1A36AAB4-77CD-489F-9DDF-D48963C37985@apple.com>
References: <4ADC7920.40309@mymail.mines.edu> <4ADC79F3.7050602@gmail.com>
	<4ADC86AD.1070503@mymail.mines.edu>
	<ACD46929-2653-4C75-B32B-E6D3F46647E0@apple.com>
	<4ADC9229.2080900@mymail.mines.edu>
	<1A36AAB4-77CD-489F-9DDF-D48963C37985@apple.com>
Message-ID: <4AE630A8.8080601@mymail.mines.edu>

Douglas Gregor wrote:
> 
> On Oct 19, 2009, at 9:22 AM, Charles Davis wrote:
> 
>> Douglas Gregor wrote:
>>>
>>> On Oct 19, 2009, at 8:33 AM, Charles Davis wrote:
>>>> As I said earlier (in an email some of you may not have gotten, I got a
>>>> bunch of warning diagnostics about
>>>> __attribute__((__force_align_arg_pointer__)), which, according to a
>>>> comment in include/windef.h, is supposed to ensure the stack remains
>>>> 16-byte aligned. Is this needed under clang for __stdcall functions on
>>>> Mac OS X? It's apparently needed under gcc.
>>>
>>> We don't have support for this attribute in Clang, and I don't know
>>> whether it is necessary for what you're doing. Please file an extension
>>> request at
>>>
>>>    http://llvm.org/bugs/
>> You don't? Well then, I guess, to be on the safe side, I should file a
>> request.
> 
> Thanks, I see it at http://llvm.org/bugs/show_bug.cgi?id=5254
> 
>>>> Speaking of __stdcall, I got some diagnostics related to
>>>> __attribute__((__stdcall__)) being used on function pointers. gcc does
>>>> not complain about this. Is this a known issue?
>>>
>>> Not one I know about. What diagnostics on what code?
>> Basically, any code that defines a __stdcall function pointer typedef,
>> like this one for example:
>>
>> ../../include/winnt.h:5034:15: warning: '__stdcall__' attribute only
>> applies to
>> function types
>> typedef VOID (NTAPI * PFLS_CALLBACK_FUNCTION) ( PVOID );
>>              ^
>> ../../include/winnt.h:44:15: note: instantiated from:
>> #define NTAPI __stdcall
>>              ^../../include/windef.h:57:38: note: instantiated from:
>> #    define __stdcall __attribute__((__stdcall__))
>> __attribute__((__force_align_
>> arg_pointer__))                                     ^
> 
> 
> This boils down to, e.g.,
> 
>     typedef void (__attribute__((stdcall)) * callback)(int, int);
> 
> which we complain about:
> 
> stdcall.c:1:30: warning: 'stdcall' attribute only applies to function types
> typedef void (__attribute__((stdcall)) * callback)(int, int);
>                              ^
> 
> Basically, we don't yet have a way to encode the stdcall attribute in
> the type system, so we can't form a function pointer to a stdcall
> function. I've filed a PR for this, here:
> 
>     http://llvm.org/bugs/show_bug.cgi?id=5310
You did? But I already filed one here:

      http://llvm.org/bugs/show_bug.cgi?id=5280

And then someone filed a dupe here:

      http://llvm.org/bugs/show_bug.cgi?id=5303
> 
>     - Doug

Took you a while to get back to me on this. Oh well, I've seen the
commit logs. You guys are busy with C++ support, so this is
understandable. Anyway, thanks.

Chip

From dgregor at apple.com  Mon Oct 26 18:37:30 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 26 Oct 2009 16:37:30 -0700
Subject: [cfe-dev] Building Wine with clang on Mac OS X 10.6
In-Reply-To: <4AE630A8.8080601@mymail.mines.edu>
References: <4ADC7920.40309@mymail.mines.edu> <4ADC79F3.7050602@gmail.com>
	<4ADC86AD.1070503@mymail.mines.edu>
	<ACD46929-2653-4C75-B32B-E6D3F46647E0@apple.com>
	<4ADC9229.2080900@mymail.mines.edu>
	<1A36AAB4-77CD-489F-9DDF-D48963C37985@apple.com>
	<4AE630A8.8080601@mymail.mines.edu>
Message-ID: <FBDC7E7F-A464-4155-98D7-8865D13823EC@apple.com>


On Oct 26, 2009, at 4:28 PM, Charles Davis wrote:

> Douglas Gregor wrote:
>>
>> Basically, we don't yet have a way to encode the stdcall attribute in
>> the type system, so we can't form a function pointer to a stdcall
>> function. I've filed a PR for this, here:
>>
>>    http://llvm.org/bugs/show_bug.cgi?id=5310
> You did? But I already filed one here:
>
>      http://llvm.org/bugs/show_bug.cgi?id=5280

Yikes, my mistake. Thanks for pointing that out.

> And then someone filed a dupe here:
>
>      http://llvm.org/bugs/show_bug.cgi?id=5303

Both mine and 5303 closed as duplicates.

> Took you a while to get back to me on this.

That shouldn't be typical; I was away at a C++ committee meeting for  
the week, so many things sent on the 19th or later got delayed.

	- Doug

From dgregor at apple.com  Mon Oct 26 18:45:00 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 26 Oct 2009 16:45:00 -0700
Subject: [cfe-dev] CIndex changes
In-Reply-To: <aad8390910231139v27e295fw3e1e4db9ea1f6cd0@mail.gmail.com>
References: <aad8390910231139v27e295fw3e1e4db9ea1f6cd0@mail.gmail.com>
Message-ID: <0BD69387-4F02-42B5-B9FF-EAA72E13BAB7@apple.com>


On Oct 23, 2009, at 11:39 AM, John Thompson wrote:

> Ted/Steve,
>
> Do you want me to check in my changes for DLL-izing CIndex?

Please go ahead, pending the comments below. Thanks!

> I'd like to do so, because Index.h always conflicts when I update.
> Here's a patch against the latest, with just the changes for getting  
> the DLL to build.

In this:

+// MSVC DLL import/export.
+#ifdef _MSC_VER
+  #ifdef _CINDEX_LIB_
+    #define CINDEX_LINKAGE __declspec(dllexport)
+  #else
+    #define CINDEX_LINKAGE __declspec(dllimport)
+  #endif
+#endif

we need a

#else
#  define CINDEX_LINKAGE

for non-Microsoft compilers.


-typedef void (*CXTranslationUnitIterator)(CXTranslationUnit, CXCursor,
+CINDEX_LINKAGE typedef void (*CXTranslationUnitIterator) 
(CXTranslationUnit, CXCursor,
                                            CXClientData);

We don't need dllimport/dllexport on typedefs, right?

	- Doug

From dgregor at apple.com  Mon Oct 26 19:31:26 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 26 Oct 2009 17:31:26 -0700
Subject: [cfe-dev] disabling MS extensions on some tests
In-Reply-To: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>
References: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>
Message-ID: <E792135D-22A7-4694-8F73-BA50B3931AA9@apple.com>


On Oct 21, 2009, at 12:05 PM, John Thompson wrote:

> By adding -fms-extensions=0 to some of the tests previously failing  
> on Windows, it makes these 6 tests pass on Windows.
>
> The question is, are these legitimate differences between the  
> default Clang behavior and MSVC?

Yes, except possibly for typedef-redecl.cpp; see my comment below.

> They seem sort of reasonable, but I'm not knowledgeable enough to  
> say for sure.

They match up with a few specific places where we try to match MSVC's  
behavior; comments below.

> The enclosed patch contains these changes.

Please go ahead and apply the patch for everything except typedef- 
redecl.cpp; for that file, we'll need some more information about how  
MSVC behaves to do the right thing.

> Here is the previous test output:
>
> 1>********************
> 1>FAIL: Clang::SemaTemplate/nested-name-spec-template.cpp (1664 of  
> 1692)
> 1>******************** TEST 'Clang::SemaTemplate/nested-name-spec- 
> template.cpp' FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify C:\Tools 
> \llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name- 
> spec-template.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 34: C++ requires a type specifier for all declarations
> 1>Warnings seen but not expected:
> 1>  Line 34: type specifier missing, defaults to 'int'

Makes sense. Visual C++ appears to support C's "implicit int" even in C 
++ mode, so we mimic that in Clang.

> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::Preprocessor/line-directive.c (903 of 1692)
> 1>******************** TEST 'Clang::Preprocessor/line-directive.c'  
> FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify - 
> pedantic C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E C:\Tools\llvm\tools\clang 
> \test\Preprocessor\line-directive.c 2>&1 | grep 'blonk.c:92:2:  
> error: #error ABC'
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E C:\Tools\llvm\tools\clang 
> \test\Preprocessor\line-directive.c 2>&1 | grep 'blonk.c:93:2:  
> error: #error DEF'
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "-pedantic" "C:\Tools\llvm\tools\clang\test\Preprocessor 
> \line-directive.c"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 44: redefinition of typedef 'x' is invalid in C
> 1>  Line 65: redefinition of typedef 'w' is invalid in C
> 1>Notes expected but not seen:
> 1>  Line 43: previous definition is here
> 1>  Line 64: previous definition is here

Makes sense. Visual C++ appears to support typedef redefinition even  
in C, so we mimic that in Clang.

> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::Parser/cxx-template-decl.cpp (793 of 1692)
> 1>******************** TEST 'Clang::Parser/cxx-template-decl.cpp'  
> FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify C:\Tools 
> \llvm\tools\clang\test\Parser\cxx-template-decl.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "C:\Tools\llvm\tools\clang\test\Parser\cxx-template- 
> decl.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 5: C++ requires a type specifier for all declarations
> 1>  Line 57: declaration of 'T' shadows template parameter
> 1>  Line 61: declaration of 'T' shadows template parameter
> 1>  Line 64: declaration of 'T' shadows template parameter
> 1>  Line 68: declaration of 'Size' shadows template parameter
> 1>  Line 73: shadows
> 1>  Line 78: shadows
> 1>Warnings seen but not expected:
> 1>  Line 5: type specifier missing, defaults to 'int'
> 1>Notes expected but not seen:
> 1>  Line 56: template parameter is declared here
> 1>  Line 60: template parameter is declared here
> 1>  Line 63: template parameter is declared here
> 1>  Line 67: template parameter is declared here
> 1>  Line 71: here
> 1>  Line 76: here

Okay. Visual C++ does not diagnose shadowing of template parameters,  
so we allow such shadowing in Microsoft-extensions mode.

> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/implicit-int.cpp (1290 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/implicit-int.cpp' FAILED  
> ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify C:\Tools 
> \llvm\tools\clang\test\SemaCXX\implicit-int.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 3: C++ requires a type specifier for all declarations
> 1>  Line 5: C++ requires a type specifier for all declarations
> 1>Warnings seen but not expected:
> 1>  Line 3: type specifier missing, defaults to 'int'
> 1>  Line 5: type specifier missing, defaults to 'int'

Again with the implicit-int-in-C++ extension.

> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/typedef-redecl.cpp (1352 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/typedef-redecl.cpp'  
> FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify C:\Tools 
> \llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 10: redefinition of 'result_type'
> 1>Notes expected but not seen:
> 1>  Line 9: previous definition is here

Hrm. This might actually be a Clang bug... does Visual C++ diagnose  
this as an error?

> 1>Command Output (stderr):
> 1>--
> 1>--
> 1>********************
> 1>FAIL: Clang::SemaCXX/nested-name-spec.cpp (1309 of 1692)
> 1>******************** TEST 'Clang::SemaCXX/nested-name-spec.cpp'  
> FAILED ********************
> 1>Script:
> 1>--
> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -std=c++98 - 
> verify C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp
> 1>--
> 1>Exit Code: 1
> 1>Command Output (stdout):
> 1>--
> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"  
> "-std=c++98" "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX 
> \nested-name-spec.cpp"
> 1>Command 0 Result: 1
> 1>Command 0 Output:
> 1>Command 0 Stderr:
> 1>Errors expected but not seen:
> 1>  Line 171: C++ requires a type specifier for all declarations
> 1>  Line 192: C++ requires a type specifier for all declarations
> 1>Errors seen but not expected:
> 1>  Line 195: cannot initialize 'a3' with an lvalue of type 'int'
> 1>Warnings seen but not expected:
> 1>  Line 171: type specifier missing, defaults to 'int'
> 1>  Line 192: type specifier missing, defaults to 'int'

This is the implicit-int-in-C++ extension.

Thanks for working on this!

	- Doug

From kremenek at apple.com  Mon Oct 26 20:35:57 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Mon, 26 Oct 2009 18:35:57 -0700
Subject: [cfe-dev] MemRegions - how to (re)use them right?
In-Reply-To: <4ADC77F2.2080500@tu-dresden.de>
References: <4AC21EBD.10105@tu-dresden.de>
	<9CE3C697-E3F5-49F6-A2DD-E312C8E6CC4A@apple.com>
	<4ADC77F2.2080500@tu-dresden.de>
Message-ID: <CF99B054-CE91-4456-9BB2-1967E67F512A@apple.com>

On Oct 19, 2009, at 7:30 AM, Olaf Krzikalla wrote:

> At block level the for-body contains binary assignment expressions  
> only. Now I just want to know, if and where lhs_x appears anywhere  
> in rhs_y (with x < y, let's ignore x > y for the moment). Then I  
> could expand rhs_y by replacing lhs_x with rhs_x, perhaps  
> recursively. This of course isn't that easy as it sounds: you have  
> to resolve things like *&a <-> a or a->b <-> (*a).b.
> Thus all I need is a unique identifier for lhs_x and a function  
> which for a given arbitrary rvalue-expression finds the referred  
> lhs_x identifier (if one exists). Given these my initial example  
> could be solved quite elegant:
>
> A* ptr = &temp;                  // var ptr gets ID1
> temp.a = /*expr*/;               // field var temp.a gets ID2
> temp.b = /* another_expr */;     // field var temp.b gets ID3
> *sink = temp.a;   // function detects ID2 for temp.a: expand to  
> *sink = /*expr*/: done
> *sink = ptr->b;   // function detects ID1 for ptr: expand to *sink =  
> (&temp)->b:
>                 // function detects ID3 for (&temp)->b: expand to  
> *sink  = /* another_expr */: done
>
> I think, that one feasible approach to do this is working on the AST  
> level by unifiying expressions somehow (e.g. something like a  
> unified string) and then just search for them in other unified  
> expressions. However I'm afraid that this approach isn't very  
> extensible. At least it means some work which possibly has been done.
> OTOH I've seen the MemRegions which apparently are already designed  
> so that they can act easily as these unique identifiers I mentioned  
> above. Also the PostLoad node seems to designate sub-expressions for  
> which a MemRegion exists. But the only clang part dealing with  
> MemRegions so far is the GRExprEngine and as I said I'm note sure if  
> it is what I need. Or it's me who is still not able to use  
> GRExprEngine properly for my purpose.

Hi Olaf,

Sorry for the delay in my response.

MemRegions can be viewed as the "name" or "location" of a piece of  
memory.  This is how GRExprEngine uses them, and it uses MemRegions to  
talk to StoreManager to reason about values bound to MemRegions.

MemRegion certainly can be repurposed by other clients, as  
MemRegionManager (which constructs MemRegion objects) doesn't rely on  
the rest of the path-sensitive engine.  MemRegions conceptually  
represent abstract chunks of memory.  For example, a VarRegion  
represents the memory associated with a given variable.  Regions can  
be layered on top of each other to represent field and array accesses,  
casts, and so forth.  MemRegions are constructing on demand by  
GRExprEngine when it evaluates casts, pointer decays, and so forth.   
MemRegions are uniqued by MemRegionManager.  For example, when you  
request the MemRegion for a given VarDecl, you will always get the  
same MemRegion*.

In your example above, I'm not certain if ID* symbols are the values  
bound to locations or the locations themselves.  If they are the  
locations, then you'd have:

   ID1 => VarRegion(ptr)
   ID2 => FieldRegion(VarRegion(temp), a)
   ID3 => FieldRegion(VarRegion(temp), b)

Now if ID* represent values, you're going to need something else  
besides MemRegions to keep track of location -> value bindings.  For  
example:

> *sink = ptr->b;   // function detects ID1 for ptr: expand to *sink =  
> (&temp)->b:

To get this reasoning, you need to keep track of the binding:

    VarRegion(ptr)  =>  VarRegion(temp)

which would cause the l-value of 'ptr->b' to evaluate to:

    FieldRegion(VarRegion(temp), b)

Then the r-value of 'ptr->b' expands to whatever value you track for  
the field 'b' of 'temp'.

In general, I'm not certain how much value flow logic you plan on  
implementing.  MemRegions themselves don't represent the values of  
expressions, but rather memory locations (which some expressions may  
evaluate to).  The path-sensitive engine uses SVals (short for  
"symbolic values") to represent what the symbolic result of evaluating  
an expression.  As you'll see, SVals can represent "locations" and  
"non-locations", and "locations" include MemRegions.

I guess it's not clear to me how much symbolic evaluation you plan on  
doing.  If your analysis isn't path-sensitive, how do plan on handling  
confluence points in the CFG (and loops)?

Ted

From rengolin at systemcall.org  Tue Oct 27 07:51:00 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Tue, 27 Oct 2009 12:51:00 +0000
Subject: [cfe-dev] lit tests failure
Message-ID: <d9b9d95f0910270551v5c722115kb2ff04ae7385ad8f@mail.gmail.com>

Hi all,

I'm seeing some errors on the up-to-date clang tree:

--- Running clang tests for i686-pc-linux-gnu ---
lit.py: lit.cfg:146: note: using clang:
'/home/rengol01/temp/llvm/Debug/bin/clang'
lit.py: lit.cfg:151: note: using clang-cc:
'/home/rengol01/temp/llvm/Debug/bin/clang-cc'
FAIL: Clang::CodeGen/object-size.c (389 of 1698)
FAIL: Clang::Preprocessor/assembler-with-cpp.c (858 of 1698)
FAIL: Clang::Preprocessor/output_paste_avoid.c (951 of 1698)
Testing Time: 21.15s
********************
Failing Tests (3):
    Clang::CodeGen/object-size.c
    Clang::Preprocessor/assembler-with-cpp.c
    Clang::Preprocessor/output_paste_avoid.c

  Expected Passes    : 1678
  Expected Failures  : 17
  Unexpected Failures: 3

How can I get hold of which test failed within those files?  A Line
number and method name would come handy on the error report.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From Olaf.Krzikalla at tu-dresden.de  Tue Oct 27 09:00:40 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Tue, 27 Oct 2009 15:00:40 +0100
Subject: [cfe-dev] MemRegions - how to (re)use them right?
In-Reply-To: <CF99B054-CE91-4456-9BB2-1967E67F512A@apple.com>
References: <4AC21EBD.10105@tu-dresden.de>
	<9CE3C697-E3F5-49F6-A2DD-E312C8E6CC4A@apple.com>
	<4ADC77F2.2080500@tu-dresden.de>
	<CF99B054-CE91-4456-9BB2-1967E67F512A@apple.com>
Message-ID: <4AE6FD08.9000203@tu-dresden.de>

Hi Ted,

Ted Kremenek schrieb:
> Sorry for the delay in my response.
It was just in time to put me (hopefully) on the right track.

> In your example above, I'm not certain if ID* symbols are the values 
> bound to locations or the locations themselves.  
They were meant as the locations themselves. These locations then get 
bound to values similiar to what GRExprEngine does (as I have seen, 
RegionBindings stores these bindings there).

> If they are the locations, then you'd have:
>
>   ID1 => VarRegion(ptr)
>   ID2 => FieldRegion(VarRegion(temp), a)
>   ID3 => FieldRegion(VarRegion(temp), b)
>
> Now if ID* represent values, you're going to need something else 
> besides MemRegions to keep track of location -> value bindings.  For 
> example:
>
>> *sink = ptr->b;   // function detects ID1 for ptr: expand to *sink = 
>> (&temp)->b:
>
> To get this reasoning, you need to keep track of the binding:
>
>    VarRegion(ptr)  =>  VarRegion(temp)
That is, the value of a pointer itself represents another memory region. 
However I have the strong feeling that MemRegionVal actually represents 
a different concept and value flow logic isn't implemented at all (thats 
how I interpret the FIXME comment in GRExprEngine::EvalLoad). OTOH at 
least the "pointer!=0"-constraint is stored somewhere.
> which would cause the l-value of 'ptr->b' to evaluate to:
>
>    FieldRegion(VarRegion(temp), b)
>
> Then the r-value of 'ptr->b' expands to whatever value you track for 
> the field 'b' of 'temp'.
>
> In general, I'm not certain how much value flow logic you plan on 
> implementing.  
Just some basic alias analysis. That is, the value of a pointer is 
either a simple adress-of-operator result (in that case the MemRegion of 
the &-op-subexpression is bound to the pointer) or another simple 
pointer. Of course I try to make this as extensible as possible. For the 
value flow of non-pointer types the means provided by the MemRegion 
concept are sufficient.
> MemRegions themselves don't represent the values of expressions, but 
> rather memory locations (which some expressions may evaluate to).  The 
> path-sensitive engine uses SVals (short for "symbolic values") to 
> represent what the symbolic result of evaluating an expression.  As 
> you'll see, SVals can represent "locations" and "non-locations", and 
> "locations" include MemRegions.
But as I said above I don't think they are used in GRExprEngine in the 
way I want to use them.

>
> If your analysis isn't path-sensitive, how do plan on handling 
> confluence points in the CFG (and loops)?
Rather pragmatic. For the moment I will analyse basic blocks only. Later 
on this can be refined. E.g. at confluence points you may check if a 
pointer value remains or becomes the same on both paths. Then you can 
use this value further. Otherwise the pointer gets marked as unknown.

Overall I think that I can't use the xxxEngine framework but I have to 
write new components. However I think its possible to factor out the 
part creating MemRegions in a common Stmt visitor (apparently 
RegionStore and BasicStore don't differ at this point and maybe even the 
NOTE comment and the following if clause in 
RegionStoreManager::getLValueFieldOrIvar belongs to 
BasicStoreManager::getLValueField too). With this tool I should be able 
to resolve the first write to sink in my example. Then, in a second step 
I reason about pointer values. However for this second step IMHO a class 
like UnknownTypedRegion is still missing. Example:

void foo(int* x)
{
  int* y = x;
  //...
}

Even if I don't know the particular MemRegion x points to, I know that y 
points to the same region.
I hope to get some first results by the end of week. Meanwhile I'm still 
eager to get your comments.


Ciao Olaf










From dgregor at apple.com  Tue Oct 27 09:30:23 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 27 Oct 2009 07:30:23 -0700
Subject: [cfe-dev] lit tests failure
In-Reply-To: <d9b9d95f0910270551v5c722115kb2ff04ae7385ad8f@mail.gmail.com>
References: <d9b9d95f0910270551v5c722115kb2ff04ae7385ad8f@mail.gmail.com>
Message-ID: <DA6537D9-DF77-46B0-8096-D9AF5D7E184E@apple.com>

Hi Renato,

On Oct 27, 2009, at 5:51 AM, Renato Golin wrote:
> I'm seeing some errors on the up-to-date clang tree:
>
> --- Running clang tests for i686-pc-linux-gnu ---
> lit.py: lit.cfg:146: note: using clang:
> '/home/rengol01/temp/llvm/Debug/bin/clang'
> lit.py: lit.cfg:151: note: using clang-cc:
> '/home/rengol01/temp/llvm/Debug/bin/clang-cc'
> FAIL: Clang::CodeGen/object-size.c (389 of 1698)
> FAIL: Clang::Preprocessor/assembler-with-cpp.c (858 of 1698)
> FAIL: Clang::Preprocessor/output_paste_avoid.c (951 of 1698)
> Testing Time: 21.15s
> ********************
> Failing Tests (3):
>    Clang::CodeGen/object-size.c
>    Clang::Preprocessor/assembler-with-cpp.c
>    Clang::Preprocessor/output_paste_avoid.c
>
>  Expected Passes    : 1678
>  Expected Failures  : 17
>  Unexpected Failures: 3
>
> How can I get hold of which test failed within those files?  A Line
> number and method name would come handy on the error report.

Run lit with the "-v" parameter to get more information about the  
tests being run. Personally, I like to use lit -sv to get verbose  
output just for the failures (but succinct output everywhere else).

Those three failures look like they are now fixed.

	- Doug

From rengolin at systemcall.org  Tue Oct 27 09:38:23 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Tue, 27 Oct 2009 14:38:23 +0000
Subject: [cfe-dev] lit tests failure
In-Reply-To: <DA6537D9-DF77-46B0-8096-D9AF5D7E184E@apple.com>
References: <d9b9d95f0910270551v5c722115kb2ff04ae7385ad8f@mail.gmail.com>
	<DA6537D9-DF77-46B0-8096-D9AF5D7E184E@apple.com>
Message-ID: <d9b9d95f0910270738w30070031h7a9d564715632ee9@mail.gmail.com>

2009/10/27 Douglas Gregor <dgregor at apple.com>:
> Run lit with the "-v" parameter to get more information about the tests
> being run. Personally, I like to use lit -sv to get verbose output just for
> the failures (but succinct output everywhere else).

Excellent! Will use that from now on.

Btw, great work on the lit, it's very easy and straightforward to use.


> Those three failures look like they are now fixed.

Yes, just a few minutes after my post! I wish all my problems were
solved that fast... ;)

thanks!
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From john.thompson.jtsoftware at gmail.com  Tue Oct 27 09:40:24 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 27 Oct 2009 07:40:24 -0700
Subject: [cfe-dev] disabling MS extensions on some tests
In-Reply-To: <E792135D-22A7-4694-8F73-BA50B3931AA9@apple.com>
References: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>
	<E792135D-22A7-4694-8F73-BA50B3931AA9@apple.com>
Message-ID: <aad8390910270740r120f3dy67d4d53d49179a47@mail.gmail.com>

Thanks, Doug.  I've commited the one you indicated in 85236.

For typedef-redecl.cpp, it does appear that VC++ doesn't flag line 10 as an
error:

C:\Tools\llvm\tools\clang\test\SemaCXX>cl -c typedef-redecl.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for
80x86
Copyright (C) Microsoft Corporation.  All rights reserved.
typedef-redecl.cpp
typedef-redecl.cpp(6) : error C2371: 'REALLY_INT' : redefinition; different
basic types
        typedef-redecl.cpp(3) : see declaration of 'REALLY_INT'
typedef-redecl.cpp(14) : error C2371: 'Y' : redefinition; different basic
types
        typedef-redecl.cpp(13) : see declaration of 'Y'
typedef-redecl.cpp(17) : error C2371: 'Y2' : redefinition; different basic
types
        typedef-redecl.cpp(16) : see declaration of 'Y2'
typedef-redecl.cpp(20) : error C2365: 'f' : redefinition; previous
definition was 'function'
        typedef-redecl.cpp(19) : see declaration of 'f'
typedef-redecl.cpp(23) : error C2365: 'f2' : redefinition; previous
definition was 'typedef'
        typedef-redecl.cpp(22) : see declaration of 'f2'

-John

On Mon, Oct 26, 2009 at 5:31 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Oct 21, 2009, at 12:05 PM, John Thompson wrote:
>
> By adding -fms-extensions=0 to some of the tests previously failing on
>> Windows, it makes these 6 tests pass on Windows.
>>
>> The question is, are these legitimate differences between the default
>> Clang behavior and MSVC?
>>
>
> Yes, except possibly for typedef-redecl.cpp; see my comment below.
>
>
> They seem sort of reasonable, but I'm not knowledgeable enough to say for
>> sure.
>>
>
> They match up with a few specific places where we try to match MSVC's
> behavior; comments below.
>
>
> The enclosed patch contains these changes.
>>
>
> Please go ahead and apply the patch for everything except
> typedef-redecl.cpp; for that file, we'll need some more information about
> how MSVC behaves to do the right thing.
>
>
> Here is the previous test output:
>>
>> 1>********************
>> 1>FAIL: Clang::SemaTemplate/nested-name-spec-template.cpp (1664 of 1692)
>> 1>******************** TEST
>> 'Clang::SemaTemplate/nested-name-spec-template.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
>> C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify"
>> "C:\Tools\llvm\tools\clang\test\SemaTemplate\nested-name-spec-template.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 34: C++ requires a type specifier for all declarations
>> 1>Warnings seen but not expected:
>> 1>  Line 34: type specifier missing, defaults to 'int'
>>
>
> Makes sense. Visual C++ appears to support C's "implicit int" even in C++
> mode, so we mimic that in Clang.
>
>
> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::Preprocessor/line-directive.c (903 of 1692)
>> 1>******************** TEST 'Clang::Preprocessor/line-directive.c' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify -pedantic
>> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E
>> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c 2>&1 | grep
>> 'blonk.c:92:2: error: #error ABC'
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -E
>> C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c 2>&1 | grep
>> 'blonk.c:93:2: error: #error DEF'
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify" "-pedantic"
>> "C:\Tools\llvm\tools\clang\test\Preprocessor\line-directive.c"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 44: redefinition of typedef 'x' is invalid in C
>> 1>  Line 65: redefinition of typedef 'w' is invalid in C
>> 1>Notes expected but not seen:
>> 1>  Line 43: previous definition is here
>> 1>  Line 64: previous definition is here
>>
>
> Makes sense. Visual C++ appears to support typedef redefinition even in C,
> so we mimic that in Clang.
>
>
> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::Parser/cxx-template-decl.cpp (793 of 1692)
>> 1>******************** TEST 'Clang::Parser/cxx-template-decl.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
>> C:\Tools\llvm\tools\clang\test\Parser\cxx-template-decl.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify" "C:\Tools\llvm\tools\clang\test\Parser\cxx-template-decl.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 5: C++ requires a type specifier for all declarations
>> 1>  Line 57: declaration of 'T' shadows template parameter
>> 1>  Line 61: declaration of 'T' shadows template parameter
>> 1>  Line 64: declaration of 'T' shadows template parameter
>> 1>  Line 68: declaration of 'Size' shadows template parameter
>> 1>  Line 73: shadows
>> 1>  Line 78: shadows
>> 1>Warnings seen but not expected:
>> 1>  Line 5: type specifier missing, defaults to 'int'
>> 1>Notes expected but not seen:
>> 1>  Line 56: template parameter is declared here
>> 1>  Line 60: template parameter is declared here
>> 1>  Line 63: template parameter is declared here
>> 1>  Line 67: template parameter is declared here
>> 1>  Line 71: here
>> 1>  Line 76: here
>>
>
> Okay. Visual C++ does not diagnose shadowing of template parameters, so we
> allow such shadowing in Microsoft-extensions mode.
>
>
> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::SemaCXX/implicit-int.cpp (1290 of 1692)
>> 1>******************** TEST 'Clang::SemaCXX/implicit-int.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
>> C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\implicit-int.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 3: C++ requires a type specifier for all declarations
>> 1>  Line 5: C++ requires a type specifier for all declarations
>> 1>Warnings seen but not expected:
>> 1>  Line 3: type specifier missing, defaults to 'int'
>> 1>  Line 5: type specifier missing, defaults to 'int'
>>
>
> Again with the implicit-int-in-C++ extension.
>
>
> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::SemaCXX/typedef-redecl.cpp (1352 of 1692)
>> 1>******************** TEST 'Clang::SemaCXX/typedef-redecl.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -verify
>> C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-verify" "C:\Tools\llvm\tools\clang\test\SemaCXX\typedef-redecl.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 10: redefinition of 'result_type'
>> 1>Notes expected but not seen:
>> 1>  Line 9: previous definition is here
>>
>
> Hrm. This might actually be a Clang bug... does Visual C++ diagnose this as
> an error?
>
>
> 1>Command Output (stderr):
>> 1>--
>> 1>--
>> 1>********************
>> 1>FAIL: Clang::SemaCXX/nested-name-spec.cpp (1309 of 1692)
>> 1>******************** TEST 'Clang::SemaCXX/nested-name-spec.cpp' FAILED
>> ********************
>> 1>Script:
>> 1>--
>> 1>C:/Tools/llvm/bin/Debug/clang-cc.exe -fsyntax-only -std=c++98 -verify
>> C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp
>> 1>--
>> 1>Exit Code: 1
>> 1>Command Output (stdout):
>> 1>--
>> 1>Command 0: "C:/Tools/llvm/bin/Debug/clang-cc.exe" "-fsyntax-only"
>> "-std=c++98" "-verify"
>> "C:\Tools\llvm\tools\clang\test\SemaCXX\nested-name-spec.cpp"
>> 1>Command 0 Result: 1
>> 1>Command 0 Output:
>> 1>Command 0 Stderr:
>> 1>Errors expected but not seen:
>> 1>  Line 171: C++ requires a type specifier for all declarations
>> 1>  Line 192: C++ requires a type specifier for all declarations
>> 1>Errors seen but not expected:
>> 1>  Line 195: cannot initialize 'a3' with an lvalue of type 'int'
>> 1>Warnings seen but not expected:
>> 1>  Line 171: type specifier missing, defaults to 'int'
>> 1>  Line 192: type specifier missing, defaults to 'int'
>>
>
> This is the implicit-int-in-C++ extension.
>
> Thanks for working on this!
>
>        - Doug
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091027/a5cd1144/attachment-0001.html 

From dgregor at apple.com  Tue Oct 27 09:48:57 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 27 Oct 2009 07:48:57 -0700
Subject: [cfe-dev] disabling MS extensions on some tests
In-Reply-To: <aad8390910270740r120f3dy67d4d53d49179a47@mail.gmail.com>
References: <aad8390910211205g1b059588m263631bdff3ac2d7@mail.gmail.com>
	<E792135D-22A7-4694-8F73-BA50B3931AA9@apple.com>
	<aad8390910270740r120f3dy67d4d53d49179a47@mail.gmail.com>
Message-ID: <B75AACF2-BBF6-4154-918B-675F45A04209@apple.com>


On Oct 27, 2009, at 7:40 AM, John Thompson wrote:

> Thanks, Doug.  I've commited the one you indicated in 85236.
>
> For typedef-redecl.cpp, it does appear that VC++ doesn't flag line  
> 10 as an error:

Okay, then it seems that we're modeling VC++'s behavior properly.  
Please go ahead and commit the remaining fixes to turn off Microsoft  
extensions for those tests. Thanks!

	- Doug

From spellegrini at dps.uibk.ac.at  Tue Oct 27 11:03:49 2009
From: spellegrini at dps.uibk.ac.at (Simone Pellegrini)
Date: Tue, 27 Oct 2009 17:03:49 +0100
Subject: [cfe-dev] CallGraph and TranslationUnits
In-Reply-To: <5400aeb80910251837n1562a70dx91342e4cbfee79fc@mail.gmail.com>
References: <4AE451A4.8020700@dps.uibk.ac.at>
	<5400aeb80910251837n1562a70dx91342e4cbfee79fc@mail.gmail.com>
Message-ID: <4AE719E5.3080403@dps.uibk.ac.at>

Hello,
I have created a patch that could make the use of CallGraph more flexible.

The main idea is that CallGraph doesn't need to depend from ASTUnit as 
what it is needed to build the call graph is the ASTContext (which can 
come from either and ASTUnit or a TranslationUnit).

cheers, Simone

Zhongxing Xu wrote:
> Hi Simone,
>
> I wrote the current implementation of callgraph months ago as an
> experimentation. It's not meant to be a stable interface. If you have
> more general interface or better implementation, patches are welcome.
>
> - Zhongxing Xu
>
> 2009/10/25 Simone Pellegrini <spellegrini at dps.uibk.ac.at>:
>   
>> Dear all,
>> the clang::CallGraph class allows to build call graphs, by using the
>> method addTU(ASTUnit&), starting from clang::ASTUnit object which (as
>> far as I understand from the API) are normally generated from PCH files .
>> However, someone ( like me for example :) ) would like to build
>> CallGraphs starting from instances of clang::idx::TranslationUnit class
>> and the current API doesn't allow that. :(
>>
>> If you look to the implementation of the addTU(ASTUnit&) method there is
>> no reason why it couldn't be possible to built a CallGraph starting from
>> a TranslationUnit object. What the method does is looking for the
>> ASTContext, and TranslationUnit objects have the same getASTContext()
>> method.
>>
>> I think there is a little bit of confusion about the API. Right now it
>> seems to be that there are two kinds of TranslationUnits (1 coming from
>> PCH files and another used by the Indexer for indexing entities) and
>> there is no homogeneous way to handle this 2 objects as they have no
>> common ancestors. Why the getASTContext() method both in ASTUnit and
>> TranslationUnit is not factorized into an interface? this will make
>> CallGraph.addTU() more generic. Or, if possible, having ASTUnit
>> implementing the TranslationUnit interface (I don't know whether there
>> is any conceptual reason that prevent ASTUnit to be a TranslationUnit).
>>
>> For the moment I was able to solve the problem by slightly changing the
>> CallGraph interface by introducing the add(clang::ids::TranslationUnit&)
>> method and by factorizing the implementations with a call to a private
>> method addAST(ASTContext&). I think things will be even easier if the
>> CallGraph is built starting from ASTContext.
>>
>> Am I missing something?
>>
>> regards, Simone P.
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>     

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CallGraph.patch
Type: text/x-patch
Size: 3672 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091027/137424ec/attachment.bin 

From john.thompson.jtsoftware at gmail.com  Tue Oct 27 13:28:33 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 27 Oct 2009 11:28:33 -0700
Subject: [cfe-dev] CIndex changes
In-Reply-To: <0BD69387-4F02-42B5-B9FF-EAA72E13BAB7@apple.com>
References: <aad8390910231139v27e295fw3e1e4db9ea1f6cd0@mail.gmail.com>
	<0BD69387-4F02-42B5-B9FF-EAA72E13BAB7@apple.com>
Message-ID: <aad8390910271128h4332e8aev62cd106f4ebba812@mail.gmail.com>

Thanks, Doug.  It's in 85234.


> we need a
>
> #else
> #  define CINDEX_LINKAGE
>
> for non-Microsoft compilers.
>

Yep, sorry, I missed that.  It's in now.

> We don't need dllimport/dllexport on typedefs, right?


Right.  I fixed this too.

How about the string problems I ran into?  Is there a consensus yet on what
to do about them?

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091027/f9da9c5c/attachment.html 

From john.thompson.jtsoftware at gmail.com  Tue Oct 27 16:51:31 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 27 Oct 2009 14:51:31 -0700
Subject: [cfe-dev] CIndex changes
In-Reply-To: <E3D91B5E-CED9-42CB-97AC-631EF64A371C@apple.com>
References: <aad8390910231139v27e295fw3e1e4db9ea1f6cd0@mail.gmail.com>
	<0BD69387-4F02-42B5-B9FF-EAA72E13BAB7@apple.com>
	<aad8390910271128h4332e8aev62cd106f4ebba812@mail.gmail.com>
	<E3D91B5E-CED9-42CB-97AC-631EF64A371C@apple.com>
Message-ID: <aad8390910271451l37f5ff93xdac84c27eb1fb04b@mail.gmail.com>

 Thanks, Ted.


> I'm sorry I've been disconnected from this.  What particular code were you
> looking at that returned a 'const char*' that referred to the buffer
> associated with a temporary std::string?
>
It's in clang_getTranslationUnitSpelling, clang_getDeclSpelling, and
clang_getCursorSpelling.  The enclosed patch with my hacky work-around will
show the specific places.

I also moved getLocationFromCursor to fix a VC++ message about the return
type not being permitted inside an extern "C" {} block.
-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091027/99267eda/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cindex_strings.patch
Type: application/octet-stream
Size: 7662 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091027/99267eda/attachment.obj 

From kremenek at apple.com  Tue Oct 27 18:59:45 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Tue, 27 Oct 2009 16:59:45 -0700
Subject: [cfe-dev] CIndex changes
In-Reply-To: <aad8390910271451l37f5ff93xdac84c27eb1fb04b@mail.gmail.com>
References: <aad8390910231139v27e295fw3e1e4db9ea1f6cd0@mail.gmail.com>
	<0BD69387-4F02-42B5-B9FF-EAA72E13BAB7@apple.com>
	<aad8390910271128h4332e8aev62cd106f4ebba812@mail.gmail.com>
	<E3D91B5E-CED9-42CB-97AC-631EF64A371C@apple.com>
	<aad8390910271451l37f5ff93xdac84c27eb1fb04b@mail.gmail.com>
Message-ID: <77D208B6-7F89-4A0E-ABC3-496694674368@apple.com>

Thanks John.  The patch makes it very clear.

The problem is that we don't want to add static data to CIndex, as we  
want the functions to be as reentrant as possible.

Steve/Doug: I believe you guys discussed this one.  Comments?

On Oct 27, 2009, at 2:51 PM, John Thompson wrote:

> Thanks, Ted.
>
> I'm sorry I've been disconnected from this.  What particular code  
> were you looking at that returned a 'const char*' that referred to  
> the buffer associated with a temporary std::string?
> It's in clang_getTranslationUnitSpelling, clang_getDeclSpelling, and  
> clang_getCursorSpelling.  The enclosed patch with my hacky work- 
> around will show the specific places.
>
> I also moved getLocationFromCursor to fix a VC++ message about the  
> return type not being permitted inside an extern "C" {} block.
> -John
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> <cindex_strings.patch>_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091027/67263b24/attachment.html 

From xuzhongxing at gmail.com  Wed Oct 28 07:25:43 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Wed, 28 Oct 2009 20:25:43 +0800
Subject: [cfe-dev] CallGraph and TranslationUnits
In-Reply-To: <4AE719E5.3080403@dps.uibk.ac.at>
References: <4AE451A4.8020700@dps.uibk.ac.at>
	<5400aeb80910251837n1562a70dx91342e4cbfee79fc@mail.gmail.com>
	<4AE719E5.3080403@dps.uibk.ac.at>
Message-ID: <5400aeb80910280525s3e1e0d63gba3450f53f19d9b7@mail.gmail.com>

Hi Simone,

The patch is applied. Next time would you please generate patch with
'svn diff'?

2009/10/28 Simone Pellegrini <spellegrini at dps.uibk.ac.at>:
> Hello,
> I have created a patch that could make the use of CallGraph more flexible.
>
> The main idea is that CallGraph doesn't need to depend from ASTUnit as what
> it is needed to build the call graph is the ASTContext (which can come from
> either and ASTUnit or a TranslationUnit).
>
> cheers, Simone
>
> Zhongxing Xu wrote:
>>
>> Hi Simone,
>>
>> I wrote the current implementation of callgraph months ago as an
>> experimentation. It's not meant to be a stable interface. If you have
>> more general interface or better implementation, patches are welcome.
>>
>> - Zhongxing Xu
>>
>> 2009/10/25 Simone Pellegrini <spellegrini at dps.uibk.ac.at>:
>>
>>>
>>> Dear all,
>>> the clang::CallGraph class allows to build call graphs, by using the
>>> method addTU(ASTUnit&), starting from clang::ASTUnit object which (as
>>> far as I understand from the API) are normally generated from PCH files .
>>> However, someone ( like me for example :) ) would like to build
>>> CallGraphs starting from instances of clang::idx::TranslationUnit class
>>> and the current API doesn't allow that. :(
>>>
>>> If you look to the implementation of the addTU(ASTUnit&) method there is
>>> no reason why it couldn't be possible to built a CallGraph starting from
>>> a TranslationUnit object. What the method does is looking for the
>>> ASTContext, and TranslationUnit objects have the same getASTContext()
>>> method.
>>>
>>> I think there is a little bit of confusion about the API. Right now it
>>> seems to be that there are two kinds of TranslationUnits (1 coming from
>>> PCH files and another used by the Indexer for indexing entities) and
>>> there is no homogeneous way to handle this 2 objects as they have no
>>> common ancestors. Why the getASTContext() method both in ASTUnit and
>>> TranslationUnit is not factorized into an interface? this will make
>>> CallGraph.addTU() more generic. Or, if possible, having ASTUnit
>>> implementing the TranslationUnit interface (I don't know whether there
>>> is any conceptual reason that prevent ASTUnit to be a TranslationUnit).
>>>
>>> For the moment I was able to solve the problem by slightly changing the
>>> CallGraph interface by introducing the add(clang::ids::TranslationUnit&)
>>> method and by factorizing the implementations with a call to a private
>>> method addAST(ASTContext&). I think things will be even easier if the
>>> CallGraph is built starting from ASTContext.
>>>
>>> Am I missing something?
>>>
>>> regards, Simone P.
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>
>

From rdivacky at freebsd.org  Wed Oct 28 07:43:31 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Wed, 28 Oct 2009 13:43:31 +0100
Subject: [cfe-dev] merging of FunctionDecl's
Message-ID: <20091028124331.GA38815@freebsd.org>

Hi,

example code:

int func(void);					(1)
extern int func (void) __asm__ ("FUNC");	(2)

int func(void) {
      return 42;
}


this piece of code has two declarators (1 and 2). When clang decides
what symbol name the code goes like this:

CodeGenModule::GetAddrOfFunction

	return GetOrCreateLLVMFunction(getMangledName(GD), Ty, GD);


the getMangledName() calls

	if (!mangleName(getMangleContext(), ND, Out)) {

which creates CXXNameMangler and tries to mangle the name via it:

    CXXNameMangler Mangler(Context, os);
    if (!Mangler.mangle(cast<NamedDecl>(D->getCanonicalDecl())))
      return false;

the CXXNameMangler::mangle() looks at __asm__(name) and uses it if available

  if (const AsmLabelAttr *ALA = D->getAttr<AsmLabelAttr>()) {
    // If we have an asm name, then we use it as the mangling.
    Out << '\01';  // LLVM IR Marker for __asm("foo")
    Out << ALA->getLabel();
    return true;
  }

the problem is that when emitting function via CodeGenModule::EmitGlobalFunctionDefinition()
only the first FunctionDecl is used. ie. if  (1) is first it will ommit
the needed __asm__ name mangling because (1) does not have any AsmLabelAttr assigned.

What is the correct solution for this? What should be done so the (2) has precedence
over (1) ?


thnx! roman

From snaroff at apple.com  Wed Oct 28 07:46:14 2009
From: snaroff at apple.com (steve naroff)
Date: Wed, 28 Oct 2009 08:46:14 -0400
Subject: [cfe-dev] CIndex changes
In-Reply-To: <77D208B6-7F89-4A0E-ABC3-496694674368@apple.com>
References: <aad8390910231139v27e295fw3e1e4db9ea1f6cd0@mail.gmail.com>
	<0BD69387-4F02-42B5-B9FF-EAA72E13BAB7@apple.com>
	<aad8390910271128h4332e8aev62cd106f4ebba812@mail.gmail.com>
	<E3D91B5E-CED9-42CB-97AC-631EF64A371C@apple.com>
	<aad8390910271451l37f5ff93xdac84c27eb1fb04b@mail.gmail.com>
	<77D208B6-7F89-4A0E-ABC3-496694674368@apple.com>
Message-ID: <799A23C0-878D-4BDA-BF73-680BE8C2C01A@apple.com>


On Oct 27, 2009, at 7:59 PM, Ted Kremenek wrote:

> Thanks John.  The patch makes it very clear.
>
> The problem is that we don't want to add static data to CIndex, as  
> we want the functions to be as reentrant as possible.
>
> Steve/Doug: I believe you guys discussed this one.  Comments?
>

Hey Ted,

We haven't discussed it yet. I expect to speak with Doug today/ 
tomorrow and make a decision by the end of the week.

snaroff

> On Oct 27, 2009, at 2:51 PM, John Thompson wrote:
>
>> Thanks, Ted.
>>
>> I'm sorry I've been disconnected from this.  What particular code  
>> were you looking at that returned a 'const char*' that referred to  
>> the buffer associated with a temporary std::string?
>> It's in clang_getTranslationUnitSpelling, clang_getDeclSpelling,  
>> and clang_getCursorSpelling.  The enclosed patch with my hacky work- 
>> around will show the specific places.
>>
>> I also moved getLocationFromCursor to fix a VC++ message about the  
>> return type not being permitted inside an extern "C" {} block.
>> -John
>>
>> -- 
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>> <cindex_strings.patch>_______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/7a7e909d/attachment.html 

From rdivacky at freebsd.org  Wed Oct 28 07:51:02 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Wed, 28 Oct 2009 13:51:02 +0100
Subject: [cfe-dev] [PATCH] -B support in clang
In-Reply-To: <20091021124131.GA52937@freebsd.org>
References: <20091021124131.GA52937@freebsd.org>
Message-ID: <20091028125102.GA39796@freebsd.org>

fwiwi:

	vlakno.cz/~rdivacky/clang-B.patch

this patch implements clang -B. someone might find it useful.


From shreyas76 at gmail.com  Wed Oct 28 10:11:05 2009
From: shreyas76 at gmail.com (shreyas krishnan)
Date: Wed, 28 Oct 2009 08:11:05 -0700
Subject: [cfe-dev] clang 2.6
Message-ID: <24389fb30910280811w29b33e6akb6c2feb242e6944@mail.gmail.com>

Hi
  How do I download clang corresponding to llvm 2.6 ?

thanks
shrey

From clattner at apple.com  Wed Oct 28 10:42:01 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 28 Oct 2009 08:42:01 -0700
Subject: [cfe-dev] clang 2.6
In-Reply-To: <24389fb30910280811w29b33e6akb6c2feb242e6944@mail.gmail.com>
References: <24389fb30910280811w29b33e6akb6c2feb242e6944@mail.gmail.com>
Message-ID: <32344DE9-7E00-4C25-AA31-42D1DDE180B1@apple.com>


On Oct 28, 2009, at 8:11 AM, shreyas krishnan wrote:

> Hi
>  How do I download clang corresponding to llvm 2.6 ?

Here ya go:
http://llvm.org/releases/download.html#2.6

-Chris

From dgregor at apple.com  Wed Oct 28 11:32:17 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 28 Oct 2009 09:32:17 -0700
Subject: [cfe-dev] merging of FunctionDecl's
In-Reply-To: <20091028124331.GA38815@freebsd.org>
References: <20091028124331.GA38815@freebsd.org>
Message-ID: <A933D57D-FD1C-4E39-B698-F17FAF924C17@apple.com>


On Oct 28, 2009, at 5:43 AM, Roman Divacky wrote:

> Hi,
>
> example code:
>
> int func(void);					(1)
> extern int func (void) __asm__ ("FUNC");	(2)
>
> int func(void) {
>      return 42;
> }
>
>
> this piece of code has two declarators (1 and 2). When clang decides
> what symbol name the code goes like this:
>
> CodeGenModule::GetAddrOfFunction
>
> 	return GetOrCreateLLVMFunction(getMangledName(GD), Ty, GD);
>
>
> the getMangledName() calls
>
> 	if (!mangleName(getMangleContext(), ND, Out)) {
>
> which creates CXXNameMangler and tries to mangle the name via it:
>
>    CXXNameMangler Mangler(Context, os);
>    if (!Mangler.mangle(cast<NamedDecl>(D->getCanonicalDecl())))
>      return false;

This is actually this issue. We should be mangling based on the  
declaration we're given, not based on the canonical declaration (which  
is the first declaration and, therefore, does not have the attribute).  
Fixed here:

	http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091026/022863.html

	- Doug

From rjmccall at apple.com  Wed Oct 28 13:03:29 2009
From: rjmccall at apple.com (John McCall)
Date: Wed, 28 Oct 2009 11:03:29 -0700
Subject: [cfe-dev] merging of FunctionDecl's
In-Reply-To: <A933D57D-FD1C-4E39-B698-F17FAF924C17@apple.com>
References: <20091028124331.GA38815@freebsd.org>
	<A933D57D-FD1C-4E39-B698-F17FAF924C17@apple.com>
Message-ID: <4AE88771.4000601@apple.com>

Douglas Gregor wrote:
> This is actually this issue. We should be mangling based on the  
> declaration we're given, not based on the canonical declaration (which  
> is the first declaration and, therefore, does not have the attribute).  
> Fixed here:
>   

Is there any compelling reason not to push this attribute onto the 
canonical declaration?  I'm not sure what exactly a canonical 
declaration is if it's not something you can always safely use without 
fearing loss of critical information.

John.

From john.thompson.jtsoftware at gmail.com  Wed Oct 28 13:08:19 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 28 Oct 2009 11:08:19 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <066A0998-FCD5-42EF-AF7D-8ED04CE022EC@apple.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
	<6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>
	<A4D41316-AA5C-4C13-9647-749A19DC0BD7@apple.com>
	<aad8390910231148m7e18191cs98f27819adfbe12f@mail.gmail.com>
	<739D813D-ABAC-47CB-9A1B-CF6EA083A030@apple.com>
	<066A0998-FCD5-42EF-AF7D-8ED04CE022EC@apple.com>
Message-ID: <aad8390910281108l3d97e764m70e9ded3cbd2eb76@mail.gmail.com>

Hi Chris and Doug,

Here's a patch with my initial stab at "__has_include" and
"__has_include_next", along with a test for it (has_include.c) and the
modified stdint.h.

To reuse some code, I had to rearrange things a bit, moving a static
function to Preprocessor, making some Preprocessor functions public, and
adding a couple of accessors.  I also broke out some of the code for
"defined" into a separate function.

The code itself I mostly hacked up from the code for "defined" and
"#include".  This included code for the angle brackets already.  Also,
because "defined" seemed to allow omitting the parentheses, I did it for
"__has_include" and "__has_include_next" also.  The "#include_next" code put
out a warning if the including file was the primary file, so I left this in
for "__has_include_next" also.

A couple of additional things that might need addressing:

Since these are Clang-specific keywords (I think), perhaps they should be
disabled in some circumstances (i.e. language mode), but I'm not sure how,
and I haven't look much into it yet how it is done elsewhere in the code.

Testing the error conditions was a bit tricky as the embedded
"expected-error" annotations affect the preprocessor, and the recovery isn't
always clear.  Also, whether or not to include an "#endif" was unclear.  I
tried the commented-out error conditions in the test, so they minimally seem
to work, but the preprocessor error recovery in general might need some
work. In some cases of including an "#endif" after an error condition, I
would get an assert at PPLexerChange.cpp, line 269.

But if the main code for this is okay, I'd like to check it in, to make it
easier to for me to keep in sync.

-John
On Sun, Oct 25, 2009 at 3:51 PM, Chris Lattner <clattner at apple.com> wrote:

> On Oct 23, 2009, at 11:53 AM, Douglas Gregor wrote:
>
>> On Oct 23, 2009, at 11:48 AM, John Thompson wrote:
>>
>> That (__has_include etc.) sounds good.  I'm assuming that is for use in a
>>> #if?
>>>
>>
>> Yes, just like __has_builtin and __has_feature.
>>
>> It probably makes sense to allow the same forms as include directives,
>> e.g.,
>>
>>        __has_include(<stdlib.h>)
>>        __has_include("stdlib.h")
>>        __has_include_next(<stdlib.h>)
>>        __has_include_next("stdlib.h")
>>
>
> This would be really really really cool.  I'd start with the plain quoted
> version, we can deal with the angled string later, but it will be trickier.
>
> -Chris
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/b3ad00bf/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hasinclude.patch
Type: application/octet-stream
Size: 19932 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/b3ad00bf/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: has_include.c
Type: application/octet-stream
Size: 2343 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/b3ad00bf/attachment-0003.obj 

From john.thompson.jtsoftware at gmail.com  Wed Oct 28 16:59:09 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 28 Oct 2009 14:59:09 -0700
Subject: [cfe-dev] Wide character test problem
Message-ID: <aad8390910281459i3415fef1m77d7d9e619a08364@mail.gmail.com>

On Windows, the type of wide characters is unsigned short, causing the
Sema/wchar.c to fail, which assumes int type.
The easiest fix seems to be to conditionalize it, as follows:

Index: test/Sema/wchar.c
===================================================================
--- test/Sema/wchar.c   (revision 85400)
+++ test/Sema/wchar.c   (working copy)
@@ -4,7 +4,11 @@
 int check_wchar_size[sizeof(*L"") == sizeof(wchar_t) ? 1 : -1];
 void foo() {
+#if defined(_WIN32) || defined(_WIN64) || defined(__CYGWIN__)
+  unsigned short t1[] = L"x";
+#else
   int t1[] = L"x";
+#endif
   wchar_t tab[] = L"x";
   int t2[] = "x";     // expected-error {{initialization}}
I considered changing the target triple, but that would lead to header
problems because of the wchar.h inclusion.

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/018961db/attachment.html 

From john.thompson.jtsoftware at gmail.com  Wed Oct 28 17:15:42 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 28 Oct 2009 15:15:42 -0700
Subject: [cfe-dev] Sema/return.c test problem on Windows
Message-ID: <aad8390910281515h2af857deva2d87acbc45d838@mail.gmail.com>

There's no _longjmp defined in MSVC.  Here's one way to fix the failing
Sema/return.c test:

Index: Sema/return.c
===================================================================
--- Sema/return.c       (revision 85400)
+++ Sema/return.c       (working copy)
@@ -203,7 +203,11 @@
   if (j)
     longjmp(test30_j, 1);
   else
+#if defined(_WIN32) || defined(_WIN64)
+    longjmp(test30_j, 2);
+#else
     _longjmp(test30_j, 1);
+#endif
 }
 typedef void test31_t(int status);


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/8c859c13/attachment.html 

From anton at korobeynikov.info  Wed Oct 28 17:16:43 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Thu, 29 Oct 2009 01:16:43 +0300
Subject: [cfe-dev] Wide character test problem
In-Reply-To: <aad8390910281459i3415fef1m77d7d9e619a08364@mail.gmail.com>
References: <aad8390910281459i3415fef1m77d7d9e619a08364@mail.gmail.com>
Message-ID: <b087fca00910281516h687e6fd9x6a00e55f44e8651a@mail.gmail.com>

Hello, John

> On Windows, the?type of wide characters is unsigned short, causing the
> Sema/wchar.c to fail, which assumes int type.
> The easiest fix seems to be to conditionalize it, as follows:
1. What's about mingw?
2. It's better to conditionalize based on -fshort-wchar option

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From john.thompson.jtsoftware at gmail.com  Wed Oct 28 17:23:39 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 28 Oct 2009 15:23:39 -0700
Subject: [cfe-dev] Wide character test problem
In-Reply-To: <b087fca00910281516h687e6fd9x6a00e55f44e8651a@mail.gmail.com>
References: <aad8390910281459i3415fef1m77d7d9e619a08364@mail.gmail.com>
	<b087fca00910281516h687e6fd9x6a00e55f44e8651a@mail.gmail.com>
Message-ID: <aad8390910281523x7df87e8fmddd11bbe15df6c71@mail.gmail.com>

Anton,

> 1. What's about mingw?
MinGW inherits the _WIN32 define.

> 2. It's better to conditionalize based on -fshort-wchar option
I'm not sure what you mean by the -fshort-wchar option.  There doesn't seem
to be such an option.  Or do you mean to add one?  Or is there an implicit
define I might use in a conditional?
Alternatively, because this is a platform assumption, we could just delete
the offending line.

-John
On Wed, Oct 28, 2009 at 3:16 PM, Anton Korobeynikov <anton at korobeynikov.info
> wrote:

> Hello, John
>
> > On Windows, the type of wide characters is unsigned short, causing the
> > Sema/wchar.c to fail, which assumes int type.
> > The easiest fix seems to be to conditionalize it, as follows:
> 1. What's about mingw?
> 2. It's better to conditionalize based on -fshort-wchar option
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/f12981a1/attachment.html 

From anton at korobeynikov.info  Wed Oct 28 17:30:22 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Thu, 29 Oct 2009 01:30:22 +0300
Subject: [cfe-dev] Wide character test problem
In-Reply-To: <aad8390910281523x7df87e8fmddd11bbe15df6c71@mail.gmail.com>
References: <aad8390910281459i3415fef1m77d7d9e619a08364@mail.gmail.com>
	<b087fca00910281516h687e6fd9x6a00e55f44e8651a@mail.gmail.com>
	<aad8390910281523x7df87e8fmddd11bbe15df6c71@mail.gmail.com>
Message-ID: <b087fca00910281530k296afdf2rfac1e149b67a194@mail.gmail.com>

Hello, John

>> 2. It's better to conditionalize based on -fshort-wchar option
> I'm not sure what you mean by the -fshort-wchar option.? There doesn't seem
> to be such an option.? Or do you mean to add one?
If it does not exist - then yes, gcc uses this option to control the
sizeof(wchar_t).

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From john.thompson.jtsoftware at gmail.com  Wed Oct 28 17:50:10 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 28 Oct 2009 15:50:10 -0700
Subject: [cfe-dev] Sema/format-strings.c test problem on Windows
Message-ID: <aad8390910281550n2043aa34md4fcbbfee6322772@mail.gmail.com>

MSVC doesn't have an snprintf, so in the enclosed patch I just declare one
for Windows.

Neither MSVC nor MinGW have a vasprintf, so it seemed reasonable to
substitute vsprintf, since only the second argument seems of interest.
Is this okay?

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/6bc7d239/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: formatstrings.patch
Type: application/octet-stream
Size: 911 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/6bc7d239/attachment.obj 

From john.thompson.jtsoftware at gmail.com  Wed Oct 28 17:51:54 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 28 Oct 2009 15:51:54 -0700
Subject: [cfe-dev] Wide character test problem
In-Reply-To: <b087fca00910281530k296afdf2rfac1e149b67a194@mail.gmail.com>
References: <aad8390910281459i3415fef1m77d7d9e619a08364@mail.gmail.com>
	<b087fca00910281516h687e6fd9x6a00e55f44e8651a@mail.gmail.com>
	<aad8390910281523x7df87e8fmddd11bbe15df6c71@mail.gmail.com>
	<b087fca00910281530k296afdf2rfac1e149b67a194@mail.gmail.com>
Message-ID: <aad8390910281551y61e7a273hf0e839199346af4f@mail.gmail.com>

Then I will look into implementing it.

Thanks, Anton.

-John

On Wed, Oct 28, 2009 at 3:30 PM, Anton Korobeynikov <anton at korobeynikov.info
> wrote:

> Hello, John
>
> >> 2. It's better to conditionalize based on -fshort-wchar option
> > I'm not sure what you mean by the -fshort-wchar option.  There doesn't
> seem
> > to be such an option.  Or do you mean to add one?
> If it does not exist - then yes, gcc uses this option to control the
> sizeof(wchar_t).
>
> --
>  With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/50786b07/attachment.html 

From clattner at apple.com  Wed Oct 28 18:33:28 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 28 Oct 2009 16:33:28 -0700
Subject: [cfe-dev] Sema/format-strings.c test problem on Windows
In-Reply-To: <aad8390910281550n2043aa34md4fcbbfee6322772@mail.gmail.com>
References: <aad8390910281550n2043aa34md4fcbbfee6322772@mail.gmail.com>
Message-ID: <4DE5B517-A272-4943-9EBA-87FE911F547F@apple.com>

looks good to me, thanks John.

On Oct 28, 2009, at 3:50 PM, John Thompson wrote:

> MSVC doesn't have an snprintf, so in the enclosed patch I just  
> declare one for Windows.
>
> Neither MSVC nor MinGW have a vasprintf, so it seemed reasonable to  
> substitute vsprintf, since only the second argument seems of interest.
> Is this okay?
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> <formatstrings.patch>_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/a1d4eac8/attachment-0001.html 

From clattner at apple.com  Wed Oct 28 18:37:38 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 28 Oct 2009 16:37:38 -0700
Subject: [cfe-dev] Sema/return.c test problem on Windows
In-Reply-To: <aad8390910281515h2af857deva2d87acbc45d838@mail.gmail.com>
References: <aad8390910281515h2af857deva2d87acbc45d838@mail.gmail.com>
Message-ID: <634E54B3-5C93-4D26-8AA0-C09B766A2BEA@apple.com>


On Oct 28, 2009, at 3:15 PM, John Thompson wrote:

> There's no _longjmp defined in MSVC.  Here's one way to fix the  
> failing Sema/return.c test:

Sure, works for me.

>
> Index: Sema/return.c
> ===================================================================
> --- Sema/return.c       (revision 85400)
> +++ Sema/return.c       (working copy)
> @@ -203,7 +203,11 @@
>    if (j)
>      longjmp(test30_j, 1);
>    else
> +#if defined(_WIN32) || defined(_WIN64)
> +    longjmp(test30_j, 2);
> +#else
>      _longjmp(test30_j, 1);
> +#endif
>  }
>  typedef void test31_t(int status);
>
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091028/34662d0f/attachment.html 

From clattner at apple.com  Wed Oct 28 23:58:42 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 28 Oct 2009 21:58:42 -0700
Subject: [cfe-dev] patch for generalizing stdint for n-bit bytes
In-Reply-To: <8F2E4A8BCDA0B84DA6C9088EB5B27747844FBF@NAMAIL.ad.onsemi.com>
References: <BB76172E-1804-45DC-AB55-18EAB0F0F41F@gmail.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B27747844567@NAMAIL.ad.onsemi.com>
	<6a8523d60910191448i3cbe3eam928a2fd8ee32d98f@mail.gmail.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B277478448A6@NAMAIL.ad.onsemi.com>
	<5AADD75D-DDCB-409C-AF92-0C72A75B587D@apple.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B27747844FBF@NAMAIL.ad.onsemi.com>
Message-ID: <9AE2B5D2-01C8-4D3F-9942-BE68441B55DB@apple.com>

On Oct 22, 2009, at 5:12 AM, Ken Dyck wrote:
>>
>> +++ lib/Basic/TargetInfo.cpp	(working copy)
>> @@ -67,12 +67,63 @@
>>    case SignedInt:        return "int";
>>    case UnsignedInt:      return "unsigned int";
>>    case SignedLong:       return "long int";
>> -  case UnsignedLong:     return "long unsigned int";
>> +  case UnsignedLong:     return "unsigned long int";
>>    case SignedLongLong:   return "long long int";
>> -  case UnsignedLongLong: return "long long unsigned int";
>> +  case UnsignedLongLong: return "unsigned long long int";
>>    }
>>  }
>>
>> Is this needed or just cleanup?
>
> More of an unrelated fix. Neither "long unsigned int" nor "long long
> unsigned int" are listed among the acceptable type specifiers in  
> section
> 6.7.2 of C99 or section 7.1.5.2 of C++98. Clang obviously must handle
> them correctly, but I figured changing them could only improve
> portability.

This is ok, because of p2: "the type specifiers may occur in any  
order, possibly intermixed with the other declaration specifiers."

I'd prefer to keep exactly the same as what GCC produces, this makes  
diffing .i files easier.

>> Please propose a patch that just uses the new methods you
>> added to simplify InitPreprocessor without changing the other
>> behavior.  That will make it easier to review the patch and
>> it will be more obviously correct (and can thus be applied
>> without thinking) :)
>
> Is the attached patch what you have in mind? Or would you like to  
> see a
> more aggressive refactoring to remove all of the literal type names  
> and
> constant suffixes from InitPreprocessor.cpp?

This is a great start, applied as r85481.  Removing the rest would be  
even better :)

>
>> The changes to stdint.h are difficult to understand from the
>> patch, but look basically reasonable to me.  In the next
>> round of patches, I'll look closer.  Just to verify, on
>> boring targets where bytes are 8 bits, no extra definitions
>> will come out of it (other than the new WIDTH macros)?
>
> There aren't any additional user macros, but there are a few more
> implementation macros. Some are for the SIG_ATOMIC definitions, which
> were previously hard-coded as 32-bit integers. There are also some new
> SIGNED macros so stdint.h can define the correct limits for the types
> that can can be either signed or unsigned.

Ok.  Please send this as a follow on patch.

>> The testcases are very nice: please merge them together into
>> one test that uses multiple RUN lines and uses a different
>> -check-prefix to FileCheck.  Also, the RUN lines don't need
>> to fit into 80 columns, please use "clang-cc -E ... |
>> FileCheck %s" instead of using %t.
>
> How about two tests: one to test stdint.h and the other to test basic
> preprocessor initialization? That is what is in the attached patch,
> anyways.

Looks great to me, applied as r85482, thanks!

> The patch corresponds to the current stdint.h, so it can be applied
> safely now, with (or without) the InitPreprocessor.cpp changes in the
> other patch. This will provide a baseline for evaluating further  
> changes
> to stdint.h and InitPreprocessor.cpp.

Awesome, thanks Ken!

-Chris

From clattner at apple.com  Thu Oct 29 01:22:08 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 28 Oct 2009 23:22:08 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <aad8390910281108l3d97e764m70e9ded3cbd2eb76@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<918710F0-86E7-4E14-AD51-8A3CE94DD5BD@apple.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
	<6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>
	<A4D41316-AA5C-4C13-9647-749A19DC0BD7@apple.com>
	<aad8390910231148m7e18191cs98f27819adfbe12f@mail.gmail.com>
	<739D813D-ABAC-47CB-9A1B-CF6EA083A030@apple.com>
	<066A0998-FCD5-42EF-AF7D-8ED04CE022EC@apple.com>
	<aad8390910281108l3d97e764m70e9ded3cbd2eb76@mail.gmail.com>
Message-ID: <579AB6D3-2190-4538-820F-FA0100399994@apple.com>


On Oct 28, 2009, at 11:08 AM, John Thompson wrote:

> Hi Chris and Doug,
>
> Here's a patch with my initial stab at "__has_include" and  
> "__has_include_next", along with a test for it (has_include.c) and  
> the modified stdint.h.

Awesome, thanks for working on this John, some thoughts:

* these should be documented in the clang language extensions document.


+++ include/clang/Basic/TokenKinds.def	(working copy)
@@ -83,6 +83,10 @@
  PPKEYWORD(assert)
  PPKEYWORD(unassert)

+// Clang Extensions.
+PPKEYWORD(__has_include)
+PPKEYWORD(__has_include_next)

Can this be implemented like __has_builtin is?  This is actually  
registered as a macro (in lib/Lex/PPMacroExpansion.cpp) which allows  
people to do things like:

#if defined(__has_builtin) && __has_builtin(__builtin_foo)

for example.


__has_include "stdio.h"

I think it is best to require ()'s, for similarity with __has_builtin  
and to allow people without this feature to #define it away.


@@ -244,9 +244,14 @@
      return CurPPLexer == L;
    }

-  /// getCurrentLexer - Return the current file lexer being lexed  
from.  Note
+  /// getCurrentLexer - Return the current lexer being lexed from.   
Note
    /// that this ignores any potentially active macro expansions and  
_Pragma
    /// expansions going on at the time.
+  PreprocessorLexer *getCurrentLexer() const { return CurPPLexer; }
+
+  /// getCurrentFileLexer - Return the current file lexer being lexed  
from.  Note
+  /// that this ignores any potentially active macro expansions and  
_Pragma
+  /// expansions going on at the time.
    PreprocessorLexer *getCurrentFileLexer() const;

Please apply separately.

  /// This code concatenates and consumes tokens up to the '>' token.   
It returns
  /// false if the > was found, otherwise it returns true if it finds  
and consumes
  /// the EOM marker.
-static bool ConcatenateIncludeName(llvm::SmallVector<char, 128>  
&FilenameBuffer,
-                                   Preprocessor &PP) {
+bool Preprocessor::ConcatenateIncludeName(

This set of changes is ok with me, please apply it separately to  
mainline.

+/// EvaluateDefined - Process a 'defined(sym)' expression.
+static bool EvaluateDefined(PPValue &Result, Token &PeekTok,
+        DefinedTracker &DT, bool ValueLive, Preprocessor &PP) {

Splitting this out makes sense to me, but please do it as a separate  
commit.

>
> Since these are Clang-specific keywords (I think), perhaps they  
> should be disabled in some circumstances (i.e. language mode), but  
> I'm not sure how, and I haven't look much into it yet how it is done  
> elsewhere in the code.

This can be done by just not registering the 'magic' macros in no- 
extensions mode.  Please apply the pieces above as independent  
patches, and try restructuring your approach around magic macros to  
follow the lead of __has_feature and __has_builtin, sending in that  
patch for review.

Thanks again John,

-Chris

From devlists at shadowlab.org  Thu Oct 29 05:25:33 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Thu, 29 Oct 2009 11:25:33 +0100
Subject: [cfe-dev] TOT broken in release build (issue in AST/TemplateBase.h)
Message-ID: <75E86A46-1341-4D62-9F35-367E4911691D@shadowlab.org>


The 85500 commit causes build error the build when NDEBUG is not  
defined.
This is due to an issue in AST/TemplateBase.h

The Kind enum is declared conditionally, but used in many places:

#ifndef NDEBUG
   enum Kind {
     K_None,
     K_DeclaratorInfo,
     K_Expression
   } Kind;
#endif

Regards
-- Jean-Daniel


From procode at adam.com.au  Thu Oct 29 06:51:01 2009
From: procode at adam.com.au (Justin Johansson)
Date: Thu, 29 Oct 2009 22:21:01 +1030
Subject: [cfe-dev] Suggestion for improving #include error message
Message-ID: <4AE981A5.2010806@adam.com.au>

Greetings Clang people,

My name is Justin and have joined this list about 5 minutes ago.

This afternoon I downloaded LLVM 2.6 and clang as separate bundles.

I'm pleased to say that the build on Linux/Ubuntu went very smoothly.
The documentation explained quite well how to place clang under the LLVM
root/tools directory and that a build of LLVM would pick up tools/clang
and build clang as well.

Great; it worked as advertised and this is a really good start compared
to some other open source projects that have borrowed my time :-)

Better still my first "hello, clang" .c compile worked just as well 
though after
first complaining (and rightfully so) about my not #including stdio.h 
(which I
deliberately initially omitted just to see what error message might 
surface.)

So after #including stdio.h, clang hello.c faithfully compiled and 
linked the
classical hello program to a working executable.

Oh, there was another compiler complaint regarding my initial void 
main() declaring
should be returning an int and I thought "Fair enough, thanks for the 
very user
friendly error message."

include <stdio.h>

int main()
{
    printf( "Hello, clang\n");
    return 0;
}

So with this as a starting point and reading about how clang desires to 
produce
friendlier error messages compared to gcc, I wondered what might 
transpire if the
#include file could not be found (and come to think of it, at this point 
I had
absolutely no idea what directory, out of my many c/c++ compiler 
installations,
that clang was actually picking stdio.h up from.)

Accordingly I changed the #include to this:

include <stdioz.h>

and got this

~/workspace/llvm-2.6/jj $ clang hello.c
hello.c:1:10: fatal error: 'stdioz.h' file not found
#include <stdioz.h>

which was quite to be expected but this now prompts my suggestion that 
it would
be even nicer if clang told me which directories it searched for the unfound
include file "stdioz.h", i.e. if it displayed the include path.

I know this is a really small issue but me thinks little improvements like
this can be really helpful to newcomers, of which I am one.

What do you think?

Regards

Justin Johansson  (c/c++ veteran; clang newbie).



From rengolin at systemcall.org  Thu Oct 29 07:53:44 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Thu, 29 Oct 2009 12:53:44 +0000
Subject: [cfe-dev] Suggestion for improving #include error message
In-Reply-To: <4AE981A5.2010806@adam.com.au>
References: <4AE981A5.2010806@adam.com.au>
Message-ID: <d9b9d95f0910290553w8a294ccl913cf3d63d028884@mail.gmail.com>

2009/10/29 Justin Johansson <procode at adam.com.au>:
> which was quite to be expected but this now prompts my suggestion that
> it would
> be even nicer if clang told me which directories it searched for the unfound
> include file "stdioz.h", i.e. if it displayed the include path.

Hi Justin,

As you, I'm a clang newbie, but IMHO, it's a bit too much.

The way to search for headers is pretty much standard, even when you
include directories of your own (via -I flag). I think that printing a
list of searched directories and possible matches would not only
clutter the output (console width problems comes to mind) but could
potentially misguide the user of the real problem.

However, there could be a separate tool, to find headers on your
system given your configuration and compilation options, which IDEs
could run upon "file not found" errors. Or maybe a '-vv' mode that
would print lots of warnings, debug information that IDEs could parse
and do intelligent stuff with it.

But making this the default is bad for raw console users. This is easy
for IDEs, but bad for the human eye.

A good example is when you try to get a template class and misplace
the template parameters. G++ will print all the candidates, and when
using std containers the list is horrendously long and wide.

My personal view is that "file not found" is sufficient... ;)

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From cadaker at gmail.com  Thu Oct 29 08:45:34 2009
From: cadaker at gmail.com (=?ISO-8859-1?Q?Christian_Ad=E5ker?=)
Date: Thu, 29 Oct 2009 14:45:34 +0100
Subject: [cfe-dev] Suggestion for improving #include error message
In-Reply-To: <d9b9d95f0910290553w8a294ccl913cf3d63d028884@mail.gmail.com>
References: <4AE981A5.2010806@adam.com.au>
	<d9b9d95f0910290553w8a294ccl913cf3d63d028884@mail.gmail.com>
Message-ID: <199d10ce0910290645y461010b3t7ca6eac7899aa4e9@mail.gmail.com>

On Thu, Oct 29, 2009 at 1:53 PM, Renato Golin <rengolin at systemcall.org> wrote:
> However, there could be a separate tool, to find headers on your
> system given your configuration and compilation options, which IDEs
> could run upon "file not found" errors. Or maybe a '-vv' mode that
> would print lots of warnings, debug information that IDEs could parse
> and do intelligent stuff with it.

I'm new to clang too, but as far as I can see clang already has an
option -print-search-dirs that shows the search paths for programs and
libraries.

This could perhaps be extended to show include paths as well? (Or, if
gcc compatibility is an issue, maybe a new option
-print-include-dirs.)

I'm not sure that the #include compiler error needs to be more
informative, but if it should, it could instead mention
-print-search-dirs. That would be less cluttered, but still give a
hint.

//Christian

From Ken.Dyck at onsemi.com  Thu Oct 29 09:52:58 2009
From: Ken.Dyck at onsemi.com (Ken Dyck)
Date: Thu, 29 Oct 2009 07:52:58 -0700
Subject: [cfe-dev] FW:  patch for generalizing stdint for n-bit bytes
Message-ID: <8F2E4A8BCDA0B84DA6C9088EB5B277478C4F2A@NAMAIL.ad.onsemi.com>

> On Thursday, October 29, 2009 12:59 AM, Chris Lattner wrote:
> On Oct 22, 2009, at 5:12 AM, Ken Dyck wrote:
> >> Please propose a patch that just uses the new methods you added to 
> >> simplify InitPreprocessor without changing the other
> behavior.  That
> >> will make it easier to review the patch and it will be
> more obviously
> >> correct (and can thus be applied without thinking) :)
> >
> > Is the attached patch what you have in mind? Or would you
> like to see
> > a more aggressive refactoring to remove all of the literal
> type names
> > and constant suffixes from InitPreprocessor.cpp?
> 
> This is a great start, applied as r85481.  Removing the rest would be 
> even better :)

One obstacle I found to simplifying the code is that the char type is
not included in the TargetInfo::IntTy enumeration, making it necessary
to always add a special case for characters. What is the rational for
excluding characters? Would there be any objection to adding a Char type
to the enum?

> >> The changes to stdint.h are difficult to understand from the patch,

> >> but look basically reasonable to me.  In the next round of patches,

> >> I'll look closer.  Just to verify, on boring targets where bytes 
> >> are 8 bits, no extra definitions will come out of it (other than 
> >> the new WIDTH macros)?
> >
> > There aren't any additional user macros, but there are a few more 
> > implementation macros. Some are for the SIG_ATOMIC
> definitions, which
> > were previously hard-coded as 32-bit integers. There are
> also some new
> > SIGNED macros so stdint.h can define the correct limits for
> the types
> > that can can be either signed or unsigned.
> 
> Ok.  Please send this as a follow on patch.

Okay. FYI, this is the plan I'll be working from for future patches:

1. A simple reordering of typedefs in stdint.h (and corresponding test
cases) in anticipation of the next patch, which defines the types in
order of decreasing width.
2. Generalization of stdint.h for non-power-of-2 widths, along with
necessary modifications to InitPreprocessor.cpp. Only minor changes to
test cases (where long is replaced by int in some typedefs on targets
where they are the same width).
3. Parameterization of SIG_ATOMIC
4. Parameterization of limits on types that can be either signed or
unsigned.
5. Replace use of vector<char> for the definition buffer with a
raw_ostream.

Does that seem reasonable to you?

-Ken


From dgregor at apple.com  Thu Oct 29 10:26:04 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 29 Oct 2009 08:26:04 -0700
Subject: [cfe-dev] [PATCH] -B support in clang
In-Reply-To: <20091028125102.GA39796@freebsd.org>
References: <20091021124131.GA52937@freebsd.org>
	<20091028125102.GA39796@freebsd.org>
Message-ID: <64094DDB-D6AC-4C01-9913-F6DE2EC9B652@apple.com>


On Oct 28, 2009, at 5:51 AM, Roman Divacky wrote:

> fwiwi:
>
> 	vlakno.cz/~rdivacky/clang-B.patch
>
> this patch implements clang -B. someone might find it useful.


This is Daniel's domain, but I have two comments and a question:

+  // HACK
+  if (C->getArgs().hasArg(options::OPT_B)) {
+     Arg *B_dir = C->getArgs().getLastArg(options::OPT_B);
+     Prefix = B_dir->getValue(C->getArgs());
+  } else {
+     Prefix = "";
+  }
+
A "HACK" note should at least mention why it's a hack :)

+std::string Driver::GetPrefix() const {
+   return Prefix;
+}
Must we really copy the prefix string every time we call this? Please  
return an llvm::StringRef instead.

The question: this doesn't look like it implements all of the  
documented semantics of GCC's -B. Is this subset of -B useful enough  
to be included in Clang? Often, having partly-implemented features can  
cause more confusion, especially since a partially-implemented -B  
would mean that we could silently pick up different libraries or  
executables...

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091029/d2d6b5c5/attachment.html 

From dgregor at apple.com  Thu Oct 29 10:28:30 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 29 Oct 2009 08:28:30 -0700
Subject: [cfe-dev] TOT broken in release build (issue in
	AST/TemplateBase.h)
In-Reply-To: <75E86A46-1341-4D62-9F35-367E4911691D@shadowlab.org>
References: <75E86A46-1341-4D62-9F35-367E4911691D@shadowlab.org>
Message-ID: <7728027D-FD81-4D3F-9D4D-5819144BCFF9@apple.com>


On Oct 29, 2009, at 3:25 AM, Jean-Daniel Dupas wrote:

>
> The 85500 commit causes build error the build when NDEBUG is not
> defined.
> This is due to an issue in AST/TemplateBase.h
>
> The Kind enum is declared conditionally, but used in many places:
>
> #ifndef NDEBUG
>   enum Kind {
>     K_None,
>     K_DeclaratorInfo,
>     K_Expression
>   } Kind;
> #endif

Fixed in r85509; thanks for noticing this!

	- Doug

From rdivacky at freebsd.org  Thu Oct 29 10:26:37 2009
From: rdivacky at freebsd.org (Roman Divacky)
Date: Thu, 29 Oct 2009 16:26:37 +0100
Subject: [cfe-dev] [PATCH] -B support in clang
In-Reply-To: <64094DDB-D6AC-4C01-9913-F6DE2EC9B652@apple.com>
References: <20091021124131.GA52937@freebsd.org>
	<20091028125102.GA39796@freebsd.org>
	<64094DDB-D6AC-4C01-9913-F6DE2EC9B652@apple.com>
Message-ID: <20091029152637.GA80400@freebsd.org>

this patch is not going to get integrated at all. Daniel already
refused to have this functionality. I just posted it to the list
to archive it. ie. when someone in the future googles for clang -B
they can have this patch...

I have no intention to integrate it upstream

On Thu, Oct 29, 2009 at 08:26:04AM -0700, Douglas Gregor wrote:
> 
> On Oct 28, 2009, at 5:51 AM, Roman Divacky wrote:
> 
> >fwiwi:
> >
> >	vlakno.cz/~rdivacky/clang-B.patch
> >
> >this patch implements clang -B. someone might find it useful.
> 
> 
> This is Daniel's domain, but I have two comments and a question:
> 
> +  // HACK
> +  if (C->getArgs().hasArg(options::OPT_B)) {
> +     Arg *B_dir = C->getArgs().getLastArg(options::OPT_B);
> +     Prefix = B_dir->getValue(C->getArgs());
> +  } else {
> +     Prefix = "";
> +  }
> +
> A "HACK" note should at least mention why it's a hack :)
> 
> +std::string Driver::GetPrefix() const {
> +   return Prefix;
> +}
> Must we really copy the prefix string every time we call this? Please  
> return an llvm::StringRef instead.
> 
> The question: this doesn't look like it implements all of the  
> documented semantics of GCC's -B. Is this subset of -B useful enough  
> to be included in Clang? Often, having partly-implemented features can  
> cause more confusion, especially since a partially-implemented -B  
> would mean that we could silently pick up different libraries or  
> executables...
> 
> 	- Doug
> 

From john.thompson.jtsoftware at gmail.com  Thu Oct 29 10:34:07 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 29 Oct 2009 08:34:07 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <579AB6D3-2190-4538-820F-FA0100399994@apple.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
	<6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>
	<A4D41316-AA5C-4C13-9647-749A19DC0BD7@apple.com>
	<aad8390910231148m7e18191cs98f27819adfbe12f@mail.gmail.com>
	<739D813D-ABAC-47CB-9A1B-CF6EA083A030@apple.com>
	<066A0998-FCD5-42EF-AF7D-8ED04CE022EC@apple.com>
	<aad8390910281108l3d97e764m70e9ded3cbd2eb76@mail.gmail.com>
	<579AB6D3-2190-4538-820F-FA0100399994@apple.com>
Message-ID: <aad8390910290834q26f07253l707e5efed73dc108@mail.gmail.com>

Thanks, Chris.

>Can this be implemented like __has_builtin is?
Oh, I totally missed this!  Yes, I'll redo it like this.
>This can be done by just not registering the 'magic' macros in
no-extensions mode.

How is no-extensions mode detected?  I was expecting a flag in LangOptions,
but I don't see it, and there is no -fno-extensions option.  There is
a -fbuiltin option and a NoBuiltin flag in LangOptions, but that seems to be
for builtin functions, not preprocessor macros.  Or perhaps it needs
adding?  I don't see an equivalent in gcc.  Or perhaps something more
specific like "-fno-magic-macros=[0|1]" or "-fno-magic-macro=(macroname)"

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091029/7156d010/attachment.html 

From clattner at apple.com  Thu Oct 29 11:27:27 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 29 Oct 2009 09:27:27 -0700
Subject: [cfe-dev] math.h on Windows
In-Reply-To: <aad8390910290834q26f07253l707e5efed73dc108@mail.gmail.com>
References: <aad8390910131302m7f215c38mf0b0146051750789@mail.gmail.com>
	<aad8390910142040o116ce2ecr485bcdebb5fbec8d@mail.gmail.com>
	<474B2A3F-2E89-469D-827A-1CDB530B6E6B@apple.com>
	<6a8523d60910230910q1ed0959dja693ca374132f47c@mail.gmail.com>
	<A4D41316-AA5C-4C13-9647-749A19DC0BD7@apple.com>
	<aad8390910231148m7e18191cs98f27819adfbe12f@mail.gmail.com>
	<739D813D-ABAC-47CB-9A1B-CF6EA083A030@apple.com>
	<066A0998-FCD5-42EF-AF7D-8ED04CE022EC@apple.com>
	<aad8390910281108l3d97e764m70e9ded3cbd2eb76@mail.gmail.com>
	<579AB6D3-2190-4538-820F-FA0100399994@apple.com>
	<aad8390910290834q26f07253l707e5efed73dc108@mail.gmail.com>
Message-ID: <CDD15DE7-4365-46D3-80E2-6AD7101137E3@apple.com>


On Oct 29, 2009, at 8:34 AM, John Thompson wrote:

> Thanks, Chris.
>
> >Can this be implemented like __has_builtin is?
> Oh, I totally missed this!  Yes, I'll redo it like this.
> >This can be done by just not registering the 'magic' macros in no- 
> extensions mode.
>
> How is no-extensions mode detected?  I was expecting a flag in  
> LangOptions, but I don't see it, and there is no -fno-extensions  
> option.  There is a -fbuiltin option and a NoBuiltin flag in  
> LangOptions, but that seems to be for builtin functions, not  
> preprocessor macros.  Or perhaps it needs adding?  I don't see an  
> equivalent in gcc.  Or perhaps something more specific like "-fno- 
> magic-macros=[0|1]" or "-fno-magic-macro=(macroname)"
>

I would follow the lead of __has_builtin.  If it doesn't warn in some  
situation, your new thing shouldn't either :).  Since it starts with  
__ I think we're in the clear here.

-Chris


From rjmccall at apple.com  Thu Oct 29 11:43:25 2009
From: rjmccall at apple.com (John McCall)
Date: Thu, 29 Oct 2009 09:43:25 -0700
Subject: [cfe-dev] TOT broken in release build (issue
	in	AST/TemplateBase.h)
In-Reply-To: <7728027D-FD81-4D3F-9D4D-5819144BCFF9@apple.com>
References: <75E86A46-1341-4D62-9F35-367E4911691D@shadowlab.org>
	<7728027D-FD81-4D3F-9D4D-5819144BCFF9@apple.com>
Message-ID: <4AE9C62D.2090307@apple.com>

Douglas Gregor wrote:
> On Oct 29, 2009, at 3:25 AM, Jean-Daniel Dupas wrote:
>
>   
>> The 85500 commit causes build error the build when NDEBUG is not
>> defined.
>> This is due to an issue in AST/TemplateBase.h
>>
>> The Kind enum is declared conditionally, but used in many places:
>>
>> #ifndef NDEBUG
>>   enum Kind {
>>     K_None,
>>     K_DeclaratorInfo,
>>     K_Expression
>>   } Kind;
>> #endif
>>     
>
> Fixed in r85509; thanks for noticing this!
>   

Sorry about that!  I knew I should've kicked off a release build before 
going to bed.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091029/d10b17d0/attachment-0001.html 

From indeyets at gmail.com  Thu Oct 29 11:51:14 2009
From: indeyets at gmail.com (Alexey Zakhlestin)
Date: Thu, 29 Oct 2009 19:51:14 +0300
Subject: [cfe-dev] clang 2.6
In-Reply-To: <32344DE9-7E00-4C25-AA31-42D1DDE180B1@apple.com>
References: <24389fb30910280811w29b33e6akb6c2feb242e6944@mail.gmail.com>
	<32344DE9-7E00-4C25-AA31-42D1DDE180B1@apple.com>
Message-ID: <475F02E8-2645-41B5-A565-21678454FF13@gmail.com>


On 28.10.2009, at 18:42, Chris Lattner wrote:

>
> On Oct 28, 2009, at 8:11 AM, shreyas krishnan wrote:
>
>> Hi
>> How do I download clang corresponding to llvm 2.6 ?
>
> Here ya go:
> http://llvm.org/releases/download.html#2.6

Mac OS X/x86_64 is missing from there.
Will it be added?

From cdavis at mymail.mines.edu  Thu Oct 29 12:57:56 2009
From: cdavis at mymail.mines.edu (Charles Davis)
Date: Thu, 29 Oct 2009 11:57:56 -0600
Subject: [cfe-dev] Patch to add some CXX tests
Message-ID: <4AE9D7A4.9070909@mymail.mines.edu>

Hi,

I've attached a patch that adds some CXX tests for the sections
basic.def, basic.def.odr, and basic.scope from the standard. Can someone
look at this?

Thanks.

Chip
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test-cxx-basic.def-basic.def.odr-basic.scope.patch
Url: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091029/115d5961/attachment.pl 

From gg.mariotti at gmail.com  Thu Oct 29 12:19:15 2009
From: gg.mariotti at gmail.com (Giangiacomo Mariotti)
Date: Thu, 29 Oct 2009 18:19:15 +0100
Subject: [cfe-dev] One little test, comparing clang and gcc
Message-ID: <12bfabe40910291019i4b4572c4m9ec3ea8de01fb1b7@mail.gmail.com>

Hi all,
          I just wanted to try clang, so I compiled the current trunk.

clang version 1.1 (trunk 85507)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Then I compiled with it and gcc-4.4.2 the appended code with:
1) $(CC) -Wall -O0
2) $(CC) -Wall -O2
3) $(CC) -Wall -O3

No errors, good.
ls -l:
27713 2009-10-29 17:48 time_tests_clang
19346 2009-10-29 17:49 time_tests_clang_02
19346 2009-10-29 17:49 time_tests_clang_03
23329 2009-10-29 17:48 time_tests_gcc
19039 2009-10-29 17:48 time_tests_gcc_02
19039 2009-10-29 17:49 time_tests_gcc_03

strip --strip-all
ls -l:
23512 2009-10-29 17:53 time_tests_clang
15280 2009-10-29 17:53 time_tests_clang_02
15280 2009-10-29 17:53 time_tests_clang_03
19128 2009-10-29 17:52 time_tests_gcc
15008 2009-10-29 17:52 time_tests_gcc_02
15008 2009-10-29 17:52 time_tests_gcc_03

A bit bloated the unoptimized version, but the optimized version is good.

These are the sha1sums of the stripped files:

c99fed6779e4b6078b8a9eca80c64a31e741ac61  time_tests_clang
e162a06e483d14d6baa64d2bfd519b8d2e1e0d0c  time_tests_clang_02
e162a06e483d14d6baa64d2bfd519b8d2e1e0d0c  time_tests_clang_03
62579489108af5fc4bb4d4d57d4d8e5a1537b4ee  time_tests_gcc
ee582023b6acbbbb5235e674534d5949bb18fb0f  time_tests_gcc_02
5f83c4e4474001632590f5689e9eea84c537145a  time_tests_gcc_03

The -O3 switch isn't really implemented or the new optimizations
activated simply didn't find anything to modify on this code?

This is the code (taken from Programming Pearls 2nd ed., by Jon Bentley):
(with some irrelevant modifications by me)


/* Copyright (C) 1999 Lucent Technologies */
/* From 'Programming Pearls' by Jon Bentley */

/* timemod.c -- Produce table of C run time costs */

#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <math.h>

#define MAXN 100000
int x[MAXN];
int startn = 5000;
int n;

/* FUNCTIONS TO BE TIMED */

int intcmp(int *i, int *j)
{
	return *i - *j;
}

#define swapmac(i, j) { t = x[i]; x[i] = x[j]; x[j] = t; }

void swapfunc(int i, int j)
{
	int t = x[i];
	x[i] = x[j];
	x[j] = t;
}

static inline void swap_func_inline(int arr[], int i, int j)
{
	int t = arr[i];
	arr[i] = arr[j];
	arr[j] = t;
}

#define maxmac(a, b) ((a) > (b) ? (a) : (b))

int maxfunc(int a, int b)
{
	return a > b ? a : b;
}


/* WORKHORSE */

#define T(s, n)\
do {\
	typeof(s) s__ = s;\
	typeof(n) n__ = n;\
	printf("%s (n=%d)\n", s__, n__);\
} while (0)

#define TRIALS 5

#define M(op)	do {						\
	printf(" %-26s", #op);				\
	k = 0;								\
	timesum = 0;						\
	for (ex = 0; ex < TRIALS; ex++) {	\
		start = clock();				\
		for (i = 1; i <= n; i++) {		\
			fi = (float) i;				\
			for (j = 1; j <= n; j++) {	\
				op;						\
			}							\
		}								\
		t = clock()-start;				\
		printf("%8d", t);				\
		timesum += t;					\
	}									\
	nans = 1e9 * timesum / ((double)	\
		n*n * TRIALS * CLOCKS_PER_SEC);	\
	printf("%8.0f\n", nans); } while (0)


int main()
{
	int i, j, k;
	float fi, fj, fk;
	int t, ex, timesum, start, globalstart;
	double nans;

	globalstart = clock();
	for (i = 0; i < n; i++)
		x[i] = rand();
	n = startn;
	printf("C Time Cost Model, n=%d\n", n);
	T("\nInteger Arithmetic", n);
	M({});
	M(k++);
	M(k = i);
	M(k = i + j);
	M(k = i - j);
	M(k = i * j);
	M(k = i / j);
	M(k = i % j);
	M(k = i & j);
	M(k = i | j);
	T("\nFloating Point Arithmetic", n);
	M(fj=j;);
	M(fj=j; fk = fi + fj;);
	M(fj=j; fk = fi - fj;);
	M(fj=j; fk = fi * fj;);
	M(fj=j; fk = fi / fj;);
	T("\nArray Operations", n);
	M(k = i + j);
	M(k = x[i] + j);
	M(k = i + x[j]);
	M(k = x[i] + x[j]);
	T("\nComparisons", n);
	M(if (i < j) k++);
	M(if (x[i] < x[j]) k++);
	T("\nArray Comparisons and Swaps", n);
	M(k = (x[i]<x[k]) ? -1 : 1);
	M(k = intcmp(x+i, x+j));
	M(swapmac(i, j));
	M(swapfunc(i, j));
	M(swap_func_inline(x, i, j));
	T("\nMax Function, Macro and Inline", n);
	M(k = (i > j) ? i : j);
	M(k = maxmac(i, j));
	M(k = maxfunc(i, j));
	n = startn / 5;
	T("\nMath Functions", n);
	M(fk = j+fi;);
	M(k = rand(););
	M(fk = sqrt(j+fi));
	M(fk = sin(j+fi));
	M(fk = sinh(j+fi));
	M(fk = asin(j+fi));
	M(fk = cos(j+fi));
	M(fk = tan(j+fi));
	n = startn / 10;
	T("\nMemory Allocation", n);
	M(free(malloc(16)););
	M(free(malloc(100)););
	M(free(malloc(2000)););

	/* Possible additions: input, output, malloc */
	printf("\n  Secs: %4.2f\n",
		((double) clock()-globalstart)
		/ CLOCKS_PER_SEC);
	return 0;
}

These are the execution results:

->time_tests_gcc:
C Time Cost Model, n=5000

Integer Arithmetic (n=5000)
 {}                           60000   70000   60000   70000   60000       3
 k++                          60000   60000   60000   60000   70000       2
 k = i                        60000   70000   60000   70000   60000       3
 k = i + j                    60000   50000   60000   60000   50000       2
 k = i - j                    60000   60000   70000   60000   70000       3
 k = i * j                    50000   60000   50000   60000   60000       2
 k = i / j                   100000  100000  100000  110000  100000       4
 k = i % j                   100000  100000  110000  100000  100000       4
 k = i & j                    60000   50000   60000   60000   50000       2
 k = i | j                    60000   50000   60000   60000   50000       2

Floating Point Arithmetic (n=5000)
 fj=j;                        70000   60000   70000   60000   70000       3
 fj=j; fk = fi + fj;         120000  120000  120000  120000  120000       5
 fj=j; fk = fi - fj;         130000  120000  120000  120000  120000       5
 fj=j; fk = fi * fj;         130000  130000  130000  130000  130000       5
 fj=j; fk = fi / fj;         230000  220000  230000  220000  220000       9

Array Operations (n=5000)
 k = i + j                    60000   60000   50000   60000   50000       2
 k = x[i] + j                 60000   60000   50000   60000   60000       2
 k = i + x[j]                 60000   60000   60000   60000   60000       2
 k = x[i] + x[j]              70000   70000   70000   70000   70000       3

Comparisons (n=5000)
 if (i < j) k++               60000   70000   60000   60000   60000       2
 if (x[i] < x[j]) k++         70000   80000   70000   70000   80000       3

Array Comparisons and Swaps (n=5000)
 k = (x[i]<x[k]) ? -1 : 1     70000   70000   70000   80000   70000       3
 k = intcmp(x+i, x+j)        160000  160000  170000  160000  160000       6
 swapmac(i, j)               110000  120000  110000  120000  110000       5
 swapfunc(i, j)              200000  200000  200000  200000  210000       8
 swap_func_inline(x, i, j)   210000  220000  220000  210000  220000       9

Max Function, Macro and Inline (n=5000)
 k = (i > j) ? i : j          70000   70000   60000   70000   70000       3
 k = maxmac(i, j)             60000   70000   70000   70000   60000       3
 k = maxfunc(i, j)           140000  140000  140000  140000  140000       6

Math Functions (n=1000)
 fk = j+fi;                   10000       0       0       0       0       2
 k = rand();                  20000   10000   10000   10000   10000      12
 fk = sqrt(j+fi)              20000   10000   20000   20000   20000      18
 fk = sin(j+fi)               50000   60000   60000   60000   60000      58
 fk = sinh(j+fi)              30000   20000   30000   30000   30000      28
 fk = asin(j+fi)              30000   20000   30000   30000   20000      26
 fk = cos(j+fi)               60000   60000   60000   60000   60000      60
 fk = tan(j+fi)               80000   80000   90000   80000   80000      82

Memory Allocation (n=500)
 free(malloc(16));            10000   10000   10000       0   10000      32
 free(malloc(100));           10000   10000       0   10000   10000      32
 free(malloc(2000));          10000   20000   10000   10000   20000      56

  Secs: 15.40

->time_tests_clang:
C Time Cost Model, n=5000

Integer Arithmetic (n=5000)
 {}                           60000   70000   60000   70000   60000       3
 k++                          60000   50000   60000   60000   50000       2
 k = i                        70000   60000   70000   60000   70000       3
 k = i + j                    50000   60000   60000   50000   60000       2
 k = i - j                    50000   60000   60000   50000   60000       2
 k = i * j                    60000   60000   60000   60000   60000       2
 k = i / j                   100000  110000  100000  100000  100000       4
 k = i % j                   110000  100000  100000  110000  100000       4
 k = i & j                    60000   50000   60000   60000   50000       2
 k = i | j                    60000   60000   50000   60000   60000       2

Floating Point Arithmetic (n=5000)
 fj=j;                        70000   70000   80000   70000   80000       3
 fj=j; fk = fi + fj;         120000  120000  120000  120000  130000       5
 fj=j; fk = fi - fj;         120000  120000  120000  120000  120000       5
 fj=j; fk = fi * fj;         140000  130000  130000  130000  130000       5
 fj=j; fk = fi / fj;         240000  250000  240000  240000  240000      10

Array Operations (n=5000)
 k = i + j                    60000   60000   50000   60000   60000       2
 k = x[i] + j                 60000   70000   60000   70000   70000       3
 k = i + x[j]                 60000   70000   60000   70000   70000       3
 k = x[i] + x[j]              70000   80000   70000   80000   70000       3

Comparisons (n=5000)
 if (i < j) k++               60000   70000   60000   60000   60000       2
 if (x[i] < x[j]) k++         70000   80000   80000   70000   80000       3

Array Comparisons and Swaps (n=5000)
 k = (x[i]<x[k]) ? -1 : 1     80000   90000   80000   90000   90000       3
 k = intcmp(x+i, x+j)        170000  180000  170000  180000  180000       7
 swapmac(i, j)               120000  110000  120000  110000  120000       5
 swapfunc(i, j)              190000  180000  190000  190000  190000       8
 swap_func_inline(x, i, j)   220000  210000  220000  220000  220000       9

Max Function, Macro and Inline (n=5000)
 k = (i > j) ? i : j          70000   80000   80000   80000   70000       3
 k = maxmac(i, j)             80000   80000   80000   80000   80000       3
 k = maxfunc(i, j)           180000  170000  170000  170000  170000       7

Math Functions (n=1000)
 fk = j+fi;                   10000       0       0       0   10000       4
 k = rand();                  10000   10000   10000   10000   10000      10
 fk = sqrt(j+fi)              20000   20000   20000   20000   20000      20
 fk = sin(j+fi)               50000   60000   60000   50000   60000      56
 fk = sinh(j+fi)              30000   30000   30000   30000   30000      30
 fk = asin(j+fi)              30000   20000   30000   30000   30000      28
 fk = cos(j+fi)               60000   50000   60000   60000   60000      58
 fk = tan(j+fi)               80000   80000   80000   90000   80000      82

Memory Allocation (n=500)
 free(malloc(16));            10000       0   10000   10000   10000      32
 free(malloc(100));               0   10000   10000   10000       0      24
 free(malloc(2000));          20000   10000   10000   20000   10000      56

  Secs: 15.99

->time_tests_gcc_02:
C Time Cost Model, n=5000

Integer Arithmetic (n=5000)
 {}                               0       0       0       0       0       0
 k++                              0       0       0       0       0       0
 k = i                            0       0       0       0       0       0
 k = i + j                        0       0       0       0       0       0
 k = i - j                        0       0       0       0       0       0
 k = i * j                        0       0       0       0       0       0
 k = i / j                        0       0       0       0       0       0
 k = i % j                        0       0       0       0       0       0
 k = i & j                        0       0       0       0       0       0
 k = i | j                        0       0       0       0       0       0

Floating Point Arithmetic (n=5000)
 fj=j;                            0       0       0       0       0       0
 fj=j; fk = fi + fj;              0       0       0       0       0       0
 fj=j; fk = fi - fj;              0       0       0       0       0       0
 fj=j; fk = fi * fj;              0       0       0       0       0       0
 fj=j; fk = fi / fj;              0       0       0       0       0       0

Array Operations (n=5000)
 k = i + j                        0       0       0       0       0       0
 k = x[i] + j                     0       0       0       0       0       0
 k = i + x[j]                     0       0       0       0       0       0
 k = x[i] + x[j]                  0       0       0       0       0       0

Comparisons (n=5000)
 if (i < j) k++                   0       0       0       0       0       0
 if (x[i] < x[j]) k++             0       0       0       0       0       0

Array Comparisons and Swaps (n=5000)
 k = (x[i]<x[k]) ? -1 : 1         0       0       0       0       0       0
 k = intcmp(x+i, x+j)             0       0       0       0       0       0
 swapmac(i, j)                30000   30000   30000   20000   30000       1
 swapfunc(i, j)               30000   30000   30000   30000   20000       1
 swap_func_inline(x, i, j)    40000   30000   40000   30000   40000       1

Max Function, Macro and Inline (n=5000)
 k = (i > j) ? i : j              0       0       0       0       0       0
 k = maxmac(i, j)                 0       0       0       0       0       0
 k = maxfunc(i, j)                0       0       0       0       0       0

Math Functions (n=1000)
 fk = j+fi;                       0       0       0       0       0       0
 k = rand();                  10000   10000   10000   10000   10000      10
 fk = sqrt(j+fi)                  0   10000       0       0       0       2
 fk = sin(j+fi)                   0       0       0       0       0       0
 fk = sinh(j+fi)              20000   20000   20000   20000   20000      20
 fk = asin(j+fi)              20000   20000   20000   20000   20000      20
 fk = cos(j+fi)                   0       0       0       0       0       0
 fk = tan(j+fi)                   0       0       0       0       0       0

Memory Allocation (n=500)
 free(malloc(16));            10000   10000       0   10000   10000      32
 free(malloc(100));               0   10000   10000   10000   10000      32
 free(malloc(2000));          10000   10000   20000   10000   10000      48

  Secs: 0.86

->time_tests_clang_02
C Time Cost Model, n=5000

Integer Arithmetic (n=5000)
 {}                           10000   20000   20000   20000   20000       1
 k++                          20000   20000   20000   20000   20000       1
 k = i                        10000   20000   20000   20000   20000       1
 k = i + j                    20000   20000   20000   20000   10000       1
 k = i - j                    20000   20000   20000   20000   20000       1
 k = i * j                    20000   20000   20000   10000   20000       1
 k = i / j                    20000   20000   20000   20000   20000       1
 k = i % j                    20000   20000   20000   10000   20000       1
 k = i & j                    20000   20000   20000   20000   20000       1
 k = i | j                    20000   20000   10000   20000   20000       1

Floating Point Arithmetic (n=5000)
 fj=j;                        20000   20000   20000   20000   20000       1
 fj=j; fk = fi + fj;          20000   20000   20000   20000   20000       1
 fj=j; fk = fi - fj;          10000   20000   20000   20000   20000       1
 fj=j; fk = fi * fj;          20000   20000   20000   20000   20000       1
 fj=j; fk = fi / fj;          20000   20000   20000   20000   20000       1

Array Operations (n=5000)
 k = i + j                    20000   20000   10000   20000   20000       1
 k = x[i] + j                 20000   20000   20000   20000   20000       1
 k = i + x[j]                 20000   20000   20000   20000   20000       1
 k = x[i] + x[j]              20000   10000   20000   20000   20000       1

Comparisons (n=5000)
 if (i < j) k++               20000   20000   20000   20000   20000       1
 if (x[i] < x[j]) k++         20000   20000   20000   20000   10000       1

Array Comparisons and Swaps (n=5000)
 k = (x[i]<x[k]) ? -1 : 1     20000   20000   20000   20000   20000       1
 k = intcmp(x+i, x+j)         20000   20000   20000   20000   10000       1
 swapmac(i, j)                30000   30000   30000   30000   30000       1
 swapfunc(i, j)               30000   20000   30000   30000   30000       1
 swap_func_inline(x, i, j)    30000   30000   30000   30000   20000       1

Max Function, Macro and Inline (n=5000)
 k = (i > j) ? i : j          20000   20000   20000   20000   20000       1
 k = maxmac(i, j)             20000   20000   10000   20000   20000       1
 k = maxfunc(i, j)            20000   20000   20000   20000   20000       1

Math Functions (n=1000)
 fk = j+fi;                       0       0       0       0       0       0
 k = rand();                  10000   10000   10000   10000   10000      10
 fk = sqrt(j+fi)              20000   20000   20000   10000   20000      18
 fk = sin(j+fi)               60000   50000   60000   60000   50000      56
 fk = sinh(j+fi)              30000   30000   30000   20000   30000      28
 fk = asin(j+fi)              30000   30000   20000   30000   30000      28
 fk = cos(j+fi)               60000   50000   60000   60000   50000      56
 fk = tan(j+fi)               80000   80000   90000   80000   80000      82

Memory Allocation (n=500)
 free(malloc(16));                0       0       0       0       0       0
 free(malloc(100));               0       0       0       0       0       0
 free(malloc(2000));              0       0       0       0       0       0

  Secs: 4.30

->time_tests_gcc_03:
C Time Cost Model, n=5000

Integer Arithmetic (n=5000)
 {}                               0       0       0       0       0       0
 k++                              0       0       0       0       0       0
 k = i                            0       0       0       0       0       0
 k = i + j                        0       0       0       0       0       0
 k = i - j                        0       0       0       0       0       0
 k = i * j                        0       0       0       0       0       0
 k = i / j                        0       0       0       0       0       0
 k = i % j                        0       0       0       0       0       0
 k = i & j                        0       0       0       0       0       0
 k = i | j                        0       0       0       0       0       0

Floating Point Arithmetic (n=5000)
 fj=j;                            0       0       0       0       0       0
 fj=j; fk = fi + fj;              0       0       0       0       0       0
 fj=j; fk = fi - fj;              0       0       0       0       0       0
 fj=j; fk = fi * fj;              0       0       0       0       0       0
 fj=j; fk = fi / fj;              0       0       0       0       0       0

Array Operations (n=5000)
 k = i + j                        0       0       0       0       0       0
 k = x[i] + j                     0       0       0       0       0       0
 k = i + x[j]                     0       0       0       0       0       0
 k = x[i] + x[j]                  0       0       0       0       0       0

Comparisons (n=5000)
 if (i < j) k++                   0       0       0       0       0       0
 if (x[i] < x[j]) k++             0       0       0       0       0       0

Array Comparisons and Swaps (n=5000)
 k = (x[i]<x[k]) ? -1 : 1         0       0       0       0       0       0
 k = intcmp(x+i, x+j)             0       0       0       0       0       0
 swapmac(i, j)                30000   30000   30000   20000   30000       1
 swapfunc(i, j)               30000   30000   30000   30000   30000       1
 swap_func_inline(x, i, j)    30000   40000   30000   40000   30000       1

Max Function, Macro and Inline (n=5000)
 k = (i > j) ? i : j              0       0       0       0       0       0
 k = maxmac(i, j)                 0       0       0       0       0       0
 k = maxfunc(i, j)                0       0       0       0       0       0

Math Functions (n=1000)
 fk = j+fi;                       0       0       0       0       0       0
 k = rand();                  10000   10000   10000   10000   10000      10
 fk = sqrt(j+fi)                  0   10000       0       0       0       2
 fk = sin(j+fi)                   0       0       0       0       0       0
 fk = sinh(j+fi)              20000   20000   20000   20000   20000      20
 fk = asin(j+fi)              20000   20000   20000   20000   20000      20
 fk = cos(j+fi)                   0       0       0       0       0       0
 fk = tan(j+fi)                   0       0       0       0       0       0

Memory Allocation (n=500)
 free(malloc(16));            10000       0   10000   10000   10000      32
 free(malloc(100));               0   10000   10000   10000       0      24
 free(malloc(2000));          20000   10000   20000   10000   10000      56

  Secs: 0.86

time_tests_clang_02 and time_tests_clang_03 are the same, so testing
it again is irrelevant.

Disregarding the difference between time_tests_gcc_02 and
time_tests_gcc_03, which doesn't seems relevant, is the difference
between time_tests_gcc_02 and time_tests_clang_02 something expected?

I'm talking about what gcc's optimizations seems to have removed while
clang seems to have maintained. Is that a design choice or something
that simply still needs work?

Giangiacomo Mariotti

From clattner at apple.com  Thu Oct 29 14:08:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 29 Oct 2009 12:08:16 -0700
Subject: [cfe-dev] clang 2.6
In-Reply-To: <475F02E8-2645-41B5-A565-21678454FF13@gmail.com>
References: <24389fb30910280811w29b33e6akb6c2feb242e6944@mail.gmail.com>
	<32344DE9-7E00-4C25-AA31-42D1DDE180B1@apple.com>
	<475F02E8-2645-41B5-A565-21678454FF13@gmail.com>
Message-ID: <4165315A-A092-4AC6-A5D9-BB840791A410@apple.com>


On Oct 29, 2009, at 9:51 AM, Alexey Zakhlestin wrote:

>
> On 28.10.2009, at 18:42, Chris Lattner wrote:
>
>>
>> On Oct 28, 2009, at 8:11 AM, shreyas krishnan wrote:
>>
>>> Hi
>>> How do I download clang corresponding to llvm 2.6 ?
>>
>> Here ya go:
>> http://llvm.org/releases/download.html#2.6
>
> Mac OS X/x86_64 is missing from there.
> Will it be added?

The x86 binaries work on x86-64.

-Chris

From daniel at zuster.org  Thu Oct 29 14:17:02 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 29 Oct 2009 12:17:02 -0700
Subject: [cfe-dev] One little test, comparing clang and gcc
In-Reply-To: <12bfabe40910291019i4b4572c4m9ec3ea8de01fb1b7@mail.gmail.com>
References: <12bfabe40910291019i4b4572c4m9ec3ea8de01fb1b7@mail.gmail.com>
Message-ID: <6a8523d60910291217u36c1eaf1pbe67a9cfb4e41a86@mail.gmail.com>

Hi Giangiacomo,

On Thu, Oct 29, 2009 at 10:19 AM, Giangiacomo Mariotti
<gg.mariotti at gmail.com> wrote:
> Hi all,
> ? ? ? ? ?I just wanted to try clang, so I compiled the current trunk.
>
> clang version 1.1 (trunk 85507)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
>
> Then I compiled with it and gcc-4.4.2 the appended code with:
> 1) $(CC) -Wall -O0
> 2) $(CC) -Wall -O2
> 3) $(CC) -Wall -O3
>
> No errors, good.
> ls -l:
> 27713 2009-10-29 17:48 time_tests_clang
> 19346 2009-10-29 17:49 time_tests_clang_02
> 19346 2009-10-29 17:49 time_tests_clang_03
> 23329 2009-10-29 17:48 time_tests_gcc
> 19039 2009-10-29 17:48 time_tests_gcc_02
> 19039 2009-10-29 17:49 time_tests_gcc_03
>
> strip --strip-all
> ls -l:
> 23512 2009-10-29 17:53 time_tests_clang
> 15280 2009-10-29 17:53 time_tests_clang_02
> 15280 2009-10-29 17:53 time_tests_clang_03
> 19128 2009-10-29 17:52 time_tests_gcc
> 15008 2009-10-29 17:52 time_tests_gcc_02
> 15008 2009-10-29 17:52 time_tests_gcc_03
>
> A bit bloated the unoptimized version, but the optimized version is good.

Yes, clang's -O0 codegen is known to be more verbose than gcc. We'd
like to fix it, but it isn't a very high priority. Also as you
noticed, there isn't much difference between -O2 and -O3 for clang.

> These are the sha1sums of the stripped files:
>
> c99fed6779e4b6078b8a9eca80c64a31e741ac61 ?time_tests_clang
> e162a06e483d14d6baa64d2bfd519b8d2e1e0d0c ?time_tests_clang_02
> e162a06e483d14d6baa64d2bfd519b8d2e1e0d0c ?time_tests_clang_03
> 62579489108af5fc4bb4d4d57d4d8e5a1537b4ee ?time_tests_gcc
> ee582023b6acbbbb5235e674534d5949bb18fb0f ?time_tests_gcc_02
> 5f83c4e4474001632590f5689e9eea84c537145a ?time_tests_gcc_03
>
> The -O3 switch isn't really implemented or the new optimizations
> activated simply didn't find anything to modify on this code?

It's implemented, it just didn't do anything different.

> This is the code (taken from Programming Pearls 2nd ed., by Jon Bentley):
> (with some irrelevant modifications by me)
>
>
> /* Copyright (C) 1999 Lucent Technologies */
> /* From 'Programming Pearls' by Jon Bentley */
>
> /* timemod.c -- Produce table of C run time costs */
>
> #include <stdio.h>
> #include <time.h>
> #include <stdlib.h>
> #include <math.h>
>
> #define MAXN 100000
> int x[MAXN];
> int startn = 5000;
> int n;
>
> /* FUNCTIONS TO BE TIMED */
>
> int intcmp(int *i, int *j)
> {
> ? ? ? ?return *i - *j;
> }
>
> #define swapmac(i, j) { t = x[i]; x[i] = x[j]; x[j] = t; }
>
> void swapfunc(int i, int j)
> {
> ? ? ? ?int t = x[i];
> ? ? ? ?x[i] = x[j];
> ? ? ? ?x[j] = t;
> }
>
> static inline void swap_func_inline(int arr[], int i, int j)
> {
> ? ? ? ?int t = arr[i];
> ? ? ? ?arr[i] = arr[j];
> ? ? ? ?arr[j] = t;
> }
>
> #define maxmac(a, b) ((a) > (b) ? (a) : (b))
>
> int maxfunc(int a, int b)
> {
> ? ? ? ?return a > b ? a : b;
> }
>
>
> /* WORKHORSE */
>
> #define T(s, n)\
> do {\
> ? ? ? ?typeof(s) s__ = s;\
> ? ? ? ?typeof(n) n__ = n;\
> ? ? ? ?printf("%s (n=%d)\n", s__, n__);\
> } while (0)
>
> #define TRIALS 5
>
> #define M(op) ? do { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ?printf(" %-26s", #op); ? ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ?k = 0; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ?timesum = 0; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ?for (ex = 0; ex < TRIALS; ex++) { ? ? ? \
> ? ? ? ? ? ? ? ?start = clock(); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?for (i = 1; i <= n; i++) { ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ? ? ? ? ?fi = (float) i; ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ? ? ? ? ? ? ? ? ?for (j = 1; j <= n; j++) { ? ? ?\
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?op; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ? ? ? ? ? ? ? ? ?} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ? ? ? ? ?} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ? ? ? ? ?t = clock()-start; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?printf("%8d", t); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ? ? ? ? ?timesum += t; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ?} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ?nans = 1e9 * timesum / ((double) ? ? ? ?\
> ? ? ? ? ? ? ? ?n*n * TRIALS * CLOCKS_PER_SEC); \
> ? ? ? ?printf("%8.0f\n", nans); } while (0)
>
>
> int main()
> {
> ? ? ? ?int i, j, k;
> ? ? ? ?float fi, fj, fk;
> ? ? ? ?int t, ex, timesum, start, globalstart;
> ? ? ? ?double nans;
>
> ? ? ? ?globalstart = clock();
> ? ? ? ?for (i = 0; i < n; i++)
> ? ? ? ? ? ? ? ?x[i] = rand();
> ? ? ? ?n = startn;
> ? ? ? ?printf("C Time Cost Model, n=%d\n", n);
> ? ? ? ?T("\nInteger Arithmetic", n);
> ? ? ? ?M({});
> ? ? ? ?M(k++);
> ? ? ? ?M(k = i);
> ? ? ? ?M(k = i + j);
> ? ? ? ?M(k = i - j);
> ? ? ? ?M(k = i * j);
> ? ? ? ?M(k = i / j);
> ? ? ? ?M(k = i % j);
> ? ? ? ?M(k = i & j);
> ? ? ? ?M(k = i | j);
> ? ? ? ?T("\nFloating Point Arithmetic", n);
> ? ? ? ?M(fj=j;);
> ? ? ? ?M(fj=j; fk = fi + fj;);
> ? ? ? ?M(fj=j; fk = fi - fj;);
> ? ? ? ?M(fj=j; fk = fi * fj;);
> ? ? ? ?M(fj=j; fk = fi / fj;);
> ? ? ? ?T("\nArray Operations", n);
> ? ? ? ?M(k = i + j);
> ? ? ? ?M(k = x[i] + j);
> ? ? ? ?M(k = i + x[j]);
> ? ? ? ?M(k = x[i] + x[j]);
> ? ? ? ?T("\nComparisons", n);
> ? ? ? ?M(if (i < j) k++);
> ? ? ? ?M(if (x[i] < x[j]) k++);
> ? ? ? ?T("\nArray Comparisons and Swaps", n);
> ? ? ? ?M(k = (x[i]<x[k]) ? -1 : 1);
> ? ? ? ?M(k = intcmp(x+i, x+j));
> ? ? ? ?M(swapmac(i, j));
> ? ? ? ?M(swapfunc(i, j));
> ? ? ? ?M(swap_func_inline(x, i, j));
> ? ? ? ?T("\nMax Function, Macro and Inline", n);
> ? ? ? ?M(k = (i > j) ? i : j);
> ? ? ? ?M(k = maxmac(i, j));
> ? ? ? ?M(k = maxfunc(i, j));
> ? ? ? ?n = startn / 5;
> ? ? ? ?T("\nMath Functions", n);
> ? ? ? ?M(fk = j+fi;);
> ? ? ? ?M(k = rand(););
> ? ? ? ?M(fk = sqrt(j+fi));
> ? ? ? ?M(fk = sin(j+fi));
> ? ? ? ?M(fk = sinh(j+fi));
> ? ? ? ?M(fk = asin(j+fi));
> ? ? ? ?M(fk = cos(j+fi));
> ? ? ? ?M(fk = tan(j+fi));
> ? ? ? ?n = startn / 10;
> ? ? ? ?T("\nMemory Allocation", n);
> ? ? ? ?M(free(malloc(16)););
> ? ? ? ?M(free(malloc(100)););
> ? ? ? ?M(free(malloc(2000)););
>
> ? ? ? ?/* Possible additions: input, output, malloc */
> ? ? ? ?printf("\n ?Secs: %4.2f\n",
> ? ? ? ? ? ? ? ?((double) clock()-globalstart)
> ? ? ? ? ? ? ? ?/ CLOCKS_PER_SEC);
> ? ? ? ?return 0;
> }
>
> These are the execution results:
>
> ->time_tests_gcc:
> C Time Cost Model, n=5000
>
> Integer Arithmetic (n=5000)
> ?{} ? ? ? ? ? ? ? ? ? ? ? ? ? 60000 ? 70000 ? 60000 ? 70000 ? 60000 ? ? ? 3
> ?k++ ? ? ? ? ? ? ? ? ? ? ? ? ?60000 ? 60000 ? 60000 ? 60000 ? 70000 ? ? ? 2
> ?k = i ? ? ? ? ? ? ? ? ? ? ? ?60000 ? 70000 ? 60000 ? 70000 ? 60000 ? ? ? 3
> ?k = i + j ? ? ? ? ? ? ? ? ? ?60000 ? 50000 ? 60000 ? 60000 ? 50000 ? ? ? 2
> ?k = i - j ? ? ? ? ? ? ? ? ? ?60000 ? 60000 ? 70000 ? 60000 ? 70000 ? ? ? 3
> ?k = i * j ? ? ? ? ? ? ? ? ? ?50000 ? 60000 ? 50000 ? 60000 ? 60000 ? ? ? 2
> ?k = i / j ? ? ? ? ? ? ? ? ? 100000 ?100000 ?100000 ?110000 ?100000 ? ? ? 4
> ?k = i % j ? ? ? ? ? ? ? ? ? 100000 ?100000 ?110000 ?100000 ?100000 ? ? ? 4
> ?k = i & j ? ? ? ? ? ? ? ? ? ?60000 ? 50000 ? 60000 ? 60000 ? 50000 ? ? ? 2
> ?k = i | j ? ? ? ? ? ? ? ? ? ?60000 ? 50000 ? 60000 ? 60000 ? 50000 ? ? ? 2
>
> Floating Point Arithmetic (n=5000)
> ?fj=j; ? ? ? ? ? ? ? ? ? ? ? ?70000 ? 60000 ? 70000 ? 60000 ? 70000 ? ? ? 3
> ?fj=j; fk = fi + fj; ? ? ? ? 120000 ?120000 ?120000 ?120000 ?120000 ? ? ? 5
> ?fj=j; fk = fi - fj; ? ? ? ? 130000 ?120000 ?120000 ?120000 ?120000 ? ? ? 5
> ?fj=j; fk = fi * fj; ? ? ? ? 130000 ?130000 ?130000 ?130000 ?130000 ? ? ? 5
> ?fj=j; fk = fi / fj; ? ? ? ? 230000 ?220000 ?230000 ?220000 ?220000 ? ? ? 9
>
> Array Operations (n=5000)
> ?k = i + j ? ? ? ? ? ? ? ? ? ?60000 ? 60000 ? 50000 ? 60000 ? 50000 ? ? ? 2
> ?k = x[i] + j ? ? ? ? ? ? ? ? 60000 ? 60000 ? 50000 ? 60000 ? 60000 ? ? ? 2
> ?k = i + x[j] ? ? ? ? ? ? ? ? 60000 ? 60000 ? 60000 ? 60000 ? 60000 ? ? ? 2
> ?k = x[i] + x[j] ? ? ? ? ? ? ?70000 ? 70000 ? 70000 ? 70000 ? 70000 ? ? ? 3
>
> Comparisons (n=5000)
> ?if (i < j) k++ ? ? ? ? ? ? ? 60000 ? 70000 ? 60000 ? 60000 ? 60000 ? ? ? 2
> ?if (x[i] < x[j]) k++ ? ? ? ? 70000 ? 80000 ? 70000 ? 70000 ? 80000 ? ? ? 3
>
> Array Comparisons and Swaps (n=5000)
> ?k = (x[i]<x[k]) ? -1 : 1 ? ? 70000 ? 70000 ? 70000 ? 80000 ? 70000 ? ? ? 3
> ?k = intcmp(x+i, x+j) ? ? ? ?160000 ?160000 ?170000 ?160000 ?160000 ? ? ? 6
> ?swapmac(i, j) ? ? ? ? ? ? ? 110000 ?120000 ?110000 ?120000 ?110000 ? ? ? 5
> ?swapfunc(i, j) ? ? ? ? ? ? ?200000 ?200000 ?200000 ?200000 ?210000 ? ? ? 8
> ?swap_func_inline(x, i, j) ? 210000 ?220000 ?220000 ?210000 ?220000 ? ? ? 9
>
> Max Function, Macro and Inline (n=5000)
> ?k = (i > j) ? i : j ? ? ? ? ?70000 ? 70000 ? 60000 ? 70000 ? 70000 ? ? ? 3
> ?k = maxmac(i, j) ? ? ? ? ? ? 60000 ? 70000 ? 70000 ? 70000 ? 60000 ? ? ? 3
> ?k = maxfunc(i, j) ? ? ? ? ? 140000 ?140000 ?140000 ?140000 ?140000 ? ? ? 6
>
> Math Functions (n=1000)
> ?fk = j+fi; ? ? ? ? ? ? ? ? ? 10000 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 2
> ?k = rand(); ? ? ? ? ? ? ? ? ?20000 ? 10000 ? 10000 ? 10000 ? 10000 ? ? ?12
> ?fk = sqrt(j+fi) ? ? ? ? ? ? ?20000 ? 10000 ? 20000 ? 20000 ? 20000 ? ? ?18
> ?fk = sin(j+fi) ? ? ? ? ? ? ? 50000 ? 60000 ? 60000 ? 60000 ? 60000 ? ? ?58
> ?fk = sinh(j+fi) ? ? ? ? ? ? ?30000 ? 20000 ? 30000 ? 30000 ? 30000 ? ? ?28
> ?fk = asin(j+fi) ? ? ? ? ? ? ?30000 ? 20000 ? 30000 ? 30000 ? 20000 ? ? ?26
> ?fk = cos(j+fi) ? ? ? ? ? ? ? 60000 ? 60000 ? 60000 ? 60000 ? 60000 ? ? ?60
> ?fk = tan(j+fi) ? ? ? ? ? ? ? 80000 ? 80000 ? 90000 ? 80000 ? 80000 ? ? ?82
>
> Memory Allocation (n=500)
> ?free(malloc(16)); ? ? ? ? ? ?10000 ? 10000 ? 10000 ? ? ? 0 ? 10000 ? ? ?32
> ?free(malloc(100)); ? ? ? ? ? 10000 ? 10000 ? ? ? 0 ? 10000 ? 10000 ? ? ?32
> ?free(malloc(2000)); ? ? ? ? ?10000 ? 20000 ? 10000 ? 10000 ? 20000 ? ? ?56
>
> ?Secs: 15.40
>
> ->time_tests_clang:
> C Time Cost Model, n=5000
>
> Integer Arithmetic (n=5000)
> ?{} ? ? ? ? ? ? ? ? ? ? ? ? ? 60000 ? 70000 ? 60000 ? 70000 ? 60000 ? ? ? 3
> ?k++ ? ? ? ? ? ? ? ? ? ? ? ? ?60000 ? 50000 ? 60000 ? 60000 ? 50000 ? ? ? 2
> ?k = i ? ? ? ? ? ? ? ? ? ? ? ?70000 ? 60000 ? 70000 ? 60000 ? 70000 ? ? ? 3
> ?k = i + j ? ? ? ? ? ? ? ? ? ?50000 ? 60000 ? 60000 ? 50000 ? 60000 ? ? ? 2
> ?k = i - j ? ? ? ? ? ? ? ? ? ?50000 ? 60000 ? 60000 ? 50000 ? 60000 ? ? ? 2
> ?k = i * j ? ? ? ? ? ? ? ? ? ?60000 ? 60000 ? 60000 ? 60000 ? 60000 ? ? ? 2
> ?k = i / j ? ? ? ? ? ? ? ? ? 100000 ?110000 ?100000 ?100000 ?100000 ? ? ? 4
> ?k = i % j ? ? ? ? ? ? ? ? ? 110000 ?100000 ?100000 ?110000 ?100000 ? ? ? 4
> ?k = i & j ? ? ? ? ? ? ? ? ? ?60000 ? 50000 ? 60000 ? 60000 ? 50000 ? ? ? 2
> ?k = i | j ? ? ? ? ? ? ? ? ? ?60000 ? 60000 ? 50000 ? 60000 ? 60000 ? ? ? 2
>
> Floating Point Arithmetic (n=5000)
> ?fj=j; ? ? ? ? ? ? ? ? ? ? ? ?70000 ? 70000 ? 80000 ? 70000 ? 80000 ? ? ? 3
> ?fj=j; fk = fi + fj; ? ? ? ? 120000 ?120000 ?120000 ?120000 ?130000 ? ? ? 5
> ?fj=j; fk = fi - fj; ? ? ? ? 120000 ?120000 ?120000 ?120000 ?120000 ? ? ? 5
> ?fj=j; fk = fi * fj; ? ? ? ? 140000 ?130000 ?130000 ?130000 ?130000 ? ? ? 5
> ?fj=j; fk = fi / fj; ? ? ? ? 240000 ?250000 ?240000 ?240000 ?240000 ? ? ?10
>
> Array Operations (n=5000)
> ?k = i + j ? ? ? ? ? ? ? ? ? ?60000 ? 60000 ? 50000 ? 60000 ? 60000 ? ? ? 2
> ?k = x[i] + j ? ? ? ? ? ? ? ? 60000 ? 70000 ? 60000 ? 70000 ? 70000 ? ? ? 3
> ?k = i + x[j] ? ? ? ? ? ? ? ? 60000 ? 70000 ? 60000 ? 70000 ? 70000 ? ? ? 3
> ?k = x[i] + x[j] ? ? ? ? ? ? ?70000 ? 80000 ? 70000 ? 80000 ? 70000 ? ? ? 3
>
> Comparisons (n=5000)
> ?if (i < j) k++ ? ? ? ? ? ? ? 60000 ? 70000 ? 60000 ? 60000 ? 60000 ? ? ? 2
> ?if (x[i] < x[j]) k++ ? ? ? ? 70000 ? 80000 ? 80000 ? 70000 ? 80000 ? ? ? 3
>
> Array Comparisons and Swaps (n=5000)
> ?k = (x[i]<x[k]) ? -1 : 1 ? ? 80000 ? 90000 ? 80000 ? 90000 ? 90000 ? ? ? 3
> ?k = intcmp(x+i, x+j) ? ? ? ?170000 ?180000 ?170000 ?180000 ?180000 ? ? ? 7
> ?swapmac(i, j) ? ? ? ? ? ? ? 120000 ?110000 ?120000 ?110000 ?120000 ? ? ? 5
> ?swapfunc(i, j) ? ? ? ? ? ? ?190000 ?180000 ?190000 ?190000 ?190000 ? ? ? 8
> ?swap_func_inline(x, i, j) ? 220000 ?210000 ?220000 ?220000 ?220000 ? ? ? 9
>
> Max Function, Macro and Inline (n=5000)
> ?k = (i > j) ? i : j ? ? ? ? ?70000 ? 80000 ? 80000 ? 80000 ? 70000 ? ? ? 3
> ?k = maxmac(i, j) ? ? ? ? ? ? 80000 ? 80000 ? 80000 ? 80000 ? 80000 ? ? ? 3
> ?k = maxfunc(i, j) ? ? ? ? ? 180000 ?170000 ?170000 ?170000 ?170000 ? ? ? 7
>
> Math Functions (n=1000)
> ?fk = j+fi; ? ? ? ? ? ? ? ? ? 10000 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? 10000 ? ? ? 4
> ?k = rand(); ? ? ? ? ? ? ? ? ?10000 ? 10000 ? 10000 ? 10000 ? 10000 ? ? ?10
> ?fk = sqrt(j+fi) ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ?20
> ?fk = sin(j+fi) ? ? ? ? ? ? ? 50000 ? 60000 ? 60000 ? 50000 ? 60000 ? ? ?56
> ?fk = sinh(j+fi) ? ? ? ? ? ? ?30000 ? 30000 ? 30000 ? 30000 ? 30000 ? ? ?30
> ?fk = asin(j+fi) ? ? ? ? ? ? ?30000 ? 20000 ? 30000 ? 30000 ? 30000 ? ? ?28
> ?fk = cos(j+fi) ? ? ? ? ? ? ? 60000 ? 50000 ? 60000 ? 60000 ? 60000 ? ? ?58
> ?fk = tan(j+fi) ? ? ? ? ? ? ? 80000 ? 80000 ? 80000 ? 90000 ? 80000 ? ? ?82
>
> Memory Allocation (n=500)
> ?free(malloc(16)); ? ? ? ? ? ?10000 ? ? ? 0 ? 10000 ? 10000 ? 10000 ? ? ?32
> ?free(malloc(100)); ? ? ? ? ? ? ? 0 ? 10000 ? 10000 ? 10000 ? ? ? 0 ? ? ?24
> ?free(malloc(2000)); ? ? ? ? ?20000 ? 10000 ? 10000 ? 20000 ? 10000 ? ? ?56
>
> ?Secs: 15.99
>
> ->time_tests_gcc_02:
> C Time Cost Model, n=5000
>
> Integer Arithmetic (n=5000)
> ?{} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k++ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i ? ? ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i + j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i - j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i * j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i / j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i % j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i & j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i | j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Floating Point Arithmetic (n=5000)
> ?fj=j; ? ? ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fj=j; fk = fi + fj; ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fj=j; fk = fi - fj; ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fj=j; fk = fi * fj; ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fj=j; fk = fi / fj; ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Array Operations (n=5000)
> ?k = i + j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = x[i] + j ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i + x[j] ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = x[i] + x[j] ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Comparisons (n=5000)
> ?if (i < j) k++ ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?if (x[i] < x[j]) k++ ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Array Comparisons and Swaps (n=5000)
> ?k = (x[i]<x[k]) ? -1 : 1 ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = intcmp(x+i, x+j) ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?swapmac(i, j) ? ? ? ? ? ? ? ?30000 ? 30000 ? 30000 ? 20000 ? 30000 ? ? ? 1
> ?swapfunc(i, j) ? ? ? ? ? ? ? 30000 ? 30000 ? 30000 ? 30000 ? 20000 ? ? ? 1
> ?swap_func_inline(x, i, j) ? ?40000 ? 30000 ? 40000 ? 30000 ? 40000 ? ? ? 1
>
> Max Function, Macro and Inline (n=5000)
> ?k = (i > j) ? i : j ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = maxmac(i, j) ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = maxfunc(i, j) ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Math Functions (n=1000)
> ?fk = j+fi; ? ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = rand(); ? ? ? ? ? ? ? ? ?10000 ? 10000 ? 10000 ? 10000 ? 10000 ? ? ?10
> ?fk = sqrt(j+fi) ? ? ? ? ? ? ? ? ?0 ? 10000 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 2
> ?fk = sin(j+fi) ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fk = sinh(j+fi) ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ?20
> ?fk = asin(j+fi) ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ?20
> ?fk = cos(j+fi) ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fk = tan(j+fi) ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Memory Allocation (n=500)
> ?free(malloc(16)); ? ? ? ? ? ?10000 ? 10000 ? ? ? 0 ? 10000 ? 10000 ? ? ?32
> ?free(malloc(100)); ? ? ? ? ? ? ? 0 ? 10000 ? 10000 ? 10000 ? 10000 ? ? ?32
> ?free(malloc(2000)); ? ? ? ? ?10000 ? 10000 ? 20000 ? 10000 ? 10000 ? ? ?48
>
> ?Secs: 0.86
>
> ->time_tests_clang_02
> C Time Cost Model, n=5000
>
> Integer Arithmetic (n=5000)
> ?{} ? ? ? ? ? ? ? ? ? ? ? ? ? 10000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k++ ? ? ? ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = i ? ? ? ? ? ? ? ? ? ? ? ?10000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = i + j ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 10000 ? ? ? 1
> ?k = i - j ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = i * j ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 10000 ? 20000 ? ? ? 1
> ?k = i / j ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = i % j ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 10000 ? 20000 ? ? ? 1
> ?k = i & j ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = i | j ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 10000 ? 20000 ? 20000 ? ? ? 1
>
> Floating Point Arithmetic (n=5000)
> ?fj=j; ? ? ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?fj=j; fk = fi + fj; ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?fj=j; fk = fi - fj; ? ? ? ? ?10000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?fj=j; fk = fi * fj; ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?fj=j; fk = fi / fj; ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
>
> Array Operations (n=5000)
> ?k = i + j ? ? ? ? ? ? ? ? ? ?20000 ? 20000 ? 10000 ? 20000 ? 20000 ? ? ? 1
> ?k = x[i] + j ? ? ? ? ? ? ? ? 20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = i + x[j] ? ? ? ? ? ? ? ? 20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = x[i] + x[j] ? ? ? ? ? ? ?20000 ? 10000 ? 20000 ? 20000 ? 20000 ? ? ? 1
>
> Comparisons (n=5000)
> ?if (i < j) k++ ? ? ? ? ? ? ? 20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?if (x[i] < x[j]) k++ ? ? ? ? 20000 ? 20000 ? 20000 ? 20000 ? 10000 ? ? ? 1
>
> Array Comparisons and Swaps (n=5000)
> ?k = (x[i]<x[k]) ? -1 : 1 ? ? 20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = intcmp(x+i, x+j) ? ? ? ? 20000 ? 20000 ? 20000 ? 20000 ? 10000 ? ? ? 1
> ?swapmac(i, j) ? ? ? ? ? ? ? ?30000 ? 30000 ? 30000 ? 30000 ? 30000 ? ? ? 1
> ?swapfunc(i, j) ? ? ? ? ? ? ? 30000 ? 20000 ? 30000 ? 30000 ? 30000 ? ? ? 1
> ?swap_func_inline(x, i, j) ? ?30000 ? 30000 ? 30000 ? 30000 ? 20000 ? ? ? 1
>
> Max Function, Macro and Inline (n=5000)
> ?k = (i > j) ? i : j ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
> ?k = maxmac(i, j) ? ? ? ? ? ? 20000 ? 20000 ? 10000 ? 20000 ? 20000 ? ? ? 1
> ?k = maxfunc(i, j) ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ? 1
>
> Math Functions (n=1000)
> ?fk = j+fi; ? ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = rand(); ? ? ? ? ? ? ? ? ?10000 ? 10000 ? 10000 ? 10000 ? 10000 ? ? ?10
> ?fk = sqrt(j+fi) ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 10000 ? 20000 ? ? ?18
> ?fk = sin(j+fi) ? ? ? ? ? ? ? 60000 ? 50000 ? 60000 ? 60000 ? 50000 ? ? ?56
> ?fk = sinh(j+fi) ? ? ? ? ? ? ?30000 ? 30000 ? 30000 ? 20000 ? 30000 ? ? ?28
> ?fk = asin(j+fi) ? ? ? ? ? ? ?30000 ? 30000 ? 20000 ? 30000 ? 30000 ? ? ?28
> ?fk = cos(j+fi) ? ? ? ? ? ? ? 60000 ? 50000 ? 60000 ? 60000 ? 50000 ? ? ?56
> ?fk = tan(j+fi) ? ? ? ? ? ? ? 80000 ? 80000 ? 90000 ? 80000 ? 80000 ? ? ?82
>
> Memory Allocation (n=500)
> ?free(malloc(16)); ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?free(malloc(100)); ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?free(malloc(2000)); ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> ?Secs: 4.30
>
> ->time_tests_gcc_03:
> C Time Cost Model, n=5000
>
> Integer Arithmetic (n=5000)
> ?{} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k++ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i ? ? ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i + j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i - j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i * j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i / j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i % j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i & j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i | j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Floating Point Arithmetic (n=5000)
> ?fj=j; ? ? ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fj=j; fk = fi + fj; ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fj=j; fk = fi - fj; ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fj=j; fk = fi * fj; ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fj=j; fk = fi / fj; ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Array Operations (n=5000)
> ?k = i + j ? ? ? ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = x[i] + j ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = i + x[j] ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = x[i] + x[j] ? ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Comparisons (n=5000)
> ?if (i < j) k++ ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?if (x[i] < x[j]) k++ ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Array Comparisons and Swaps (n=5000)
> ?k = (x[i]<x[k]) ? -1 : 1 ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = intcmp(x+i, x+j) ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?swapmac(i, j) ? ? ? ? ? ? ? ?30000 ? 30000 ? 30000 ? 20000 ? 30000 ? ? ? 1
> ?swapfunc(i, j) ? ? ? ? ? ? ? 30000 ? 30000 ? 30000 ? 30000 ? 30000 ? ? ? 1
> ?swap_func_inline(x, i, j) ? ?30000 ? 40000 ? 30000 ? 40000 ? 30000 ? ? ? 1
>
> Max Function, Macro and Inline (n=5000)
> ?k = (i > j) ? i : j ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = maxmac(i, j) ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = maxfunc(i, j) ? ? ? ? ? ? ? ?0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Math Functions (n=1000)
> ?fk = j+fi; ? ? ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?k = rand(); ? ? ? ? ? ? ? ? ?10000 ? 10000 ? 10000 ? 10000 ? 10000 ? ? ?10
> ?fk = sqrt(j+fi) ? ? ? ? ? ? ? ? ?0 ? 10000 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 2
> ?fk = sin(j+fi) ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fk = sinh(j+fi) ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ?20
> ?fk = asin(j+fi) ? ? ? ? ? ? ?20000 ? 20000 ? 20000 ? 20000 ? 20000 ? ? ?20
> ?fk = cos(j+fi) ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
> ?fk = tan(j+fi) ? ? ? ? ? ? ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0 ? ? ? 0
>
> Memory Allocation (n=500)
> ?free(malloc(16)); ? ? ? ? ? ?10000 ? ? ? 0 ? 10000 ? 10000 ? 10000 ? ? ?32
> ?free(malloc(100)); ? ? ? ? ? ? ? 0 ? 10000 ? 10000 ? 10000 ? ? ? 0 ? ? ?24
> ?free(malloc(2000)); ? ? ? ? ?20000 ? 10000 ? 20000 ? 10000 ? 10000 ? ? ?56
>
> ?Secs: 0.86
>
> time_tests_clang_02 and time_tests_clang_03 are the same, so testing
> it again is irrelevant.
>
> Disregarding the difference between time_tests_gcc_02 and
> time_tests_gcc_03, which doesn't seems relevant, is the difference
> between time_tests_gcc_02 and time_tests_clang_02 something expected?
>
> I'm talking about what gcc's optimizations seems to have removed while
> clang seems to have maintained. Is that a design choice or something
> that simply still needs work?

I don't know the answers to these questions without digging in to your
example -- there is a lot of information here which I find hard to
read. I think you are asking about the time difference between
clang_02 and gcc_02, this is probably due to some missed optimization
which of course we always would like to fix. However, you'll have to
actually dig in to the example to find out what is going on. If you
can identify a small test case where clang clearly isn't optimizing
something it should, please file a bugzilla for it
(http://llvm.org/bugs).

 - Daniel


> Giangiacomo Mariotti
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From pcanal at fnal.gov  Thu Oct 29 16:23:48 2009
From: pcanal at fnal.gov (Philippe Canal)
Date: Thu, 29 Oct 2009 16:23:48 -0500
Subject: [cfe-dev] JIT, incremental 'linking' and global variables.
Message-ID: <4AEA07E4.7000505@fnal.gov>

Hi,

I attempting (in the context of Cling, our C++ interpreter) to 
incrementally compile and link user code,
including global variable declarations.   For example, I would like to 
compile, link, load and execute
the C++ statement:

       int i = 3;

and then compile, link, load and execute a C++ function that uses this 
global variable, for example:

   extern int i;
   int main() {
     printf("%d\n",i);
   }

But I was unable to find a workable solution.  

With the example attached (the Makefile, as is, works only on Macos),
you can reproduce my result by doing:
   
    tar xfz linking_test.tar.gz
    cd linking_test
    gmake

and then run 'tester' with 0 through 3 as argument and you should get:

$ ./tester 0
Loading declaration.cxx
Loading main.cxx
LLVM ERROR: Could not resolve external global address: i

$ ./tester 1
Loading declaration.cxx
Loading declaration.cxx
Loading main.cxx
5

$ ./tester 2
Loading declaration.cxx
Loading main.cxx
5

$ ./tester 3
Loading declaration.cxx
[i] Failure: dlopen(main.so, 9): Symbol not found: _i
  Referenced from: /Users/pcanal/root_working/code/cling_src/test/main.so
  Expected in: dynamic lookup



The only 'working' combination is "tester 2", in an ideal world "tester 
0"  and "tester 3" should also
have printed the same output.

In 'tester 0', I tried to link the 2 source files independently.   When 
executing the 2nd module it does
not find the global variable defined in the 1st module.

In 'tester 1', I tried to link the 2nd module against the 1st module. 
The execution works okay
__BUT__ all global initialization from the first module are 'redone'.

In 'tester 2', I tried  using an actual shared library containing the 
code in 'declaration.cxx' and it works
well (i.e. the loading of the  module containing main.cxx properly finds 
the 'compiled' global variable).

In 'tester 3', I tried to JIT the 1st module and then load a shared 
library containing the code of main.cxx,
here the dynamic loader does not find the declaration that was made in 
the 1st module.    Is this model
(shared library being able to see symbol that have been 'JITed') 
supported?    If not, is there any plan to
ever support it?  As an alternative, we can get this behavior if we use 
as a 'just in compiler' a forked call
to g++/clang to generate a shared library; we were hoping to be able to 
skip this fork steps.


Ideally I would like to get 'tester 0' and 'tester 3' to work as I 
expected: i.e. same output as 'tester 2'.


Does anybody know what I missed or mis-configured or if it is simply not 
supported (and if it is not, it is
planned to be supported)?

Thanks,
Philippe.

PS.  As a side note, clang inappropriately 'optimize away' something like:

int func1() { return prinf("loading the file\n"); }
static i