From xuzhongxing at gmail.com  Wed Dec  2 00:40:47 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Wed, 2 Dec 2009 14:40:47 +0800
Subject: [cfe-dev] c-index-test linking failure
In-Reply-To: <5400aeb80911070016m1389a9b7i279ca476f7deeea6@mail.gmail.com>
References: <5400aeb80911070016m1389a9b7i279ca476f7deeea6@mail.gmail.com>
Message-ID: <5400aeb80912012240q36e8a670pdd465bed5ec2af06@mail.gmail.com>

c-index-test linking fail on linux:

/usr/bin/ld: /home/xzx/llvm/Debug/bin/c-index-test: local symbol
`clang::driver::Arg::getAsString(clang::driver::ArgList const&) const'
in /home/xzx/llvm/Debug/lib/libclangDriver.a(Arg.o) is referenced by
DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output

From john.thompson.jtsoftware at gmail.com  Wed Dec  2 20:34:41 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 2 Dec 2009 18:34:41 -0800
Subject: [cfe-dev] vector function return type
Message-ID: <aad8390912021834v35ef7164i388e32b6ae9d79fb@mail.gmail.com>

I'm looking at bug 5650 about using vector return types on functions, which
is kind of difficult, not knowing all the ramifications of the type system.

For example, I need to change the return type of a function declaration, but
there aren't any accessors for that.  Is that because it's complicated?

For example, since the QualType can apparently point to something, is that
allocated storage, such that it would leak if I just assigned to it, or is
the memory managed elsewhere?  Sorry, I probably should just study it some
more.

Anyway, I've taken a stab at the bug fix, but I'm guessing it's not the
right approach.  I added a couple of setters to FunctionDecl and
FunctionType for the return type, not know if this is doable.  In the
vector_size handler, I don't try to handle all the other types that need
handling at this point, just wanting to get the vector return types to work
as a first step.

-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/20091202/4500d255/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vecreturn.patch
Type: application/octet-stream
Size: 2122 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091202/4500d255/attachment.obj 

From eli.friedman at gmail.com  Wed Dec  2 21:12:50 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 2 Dec 2009 19:12:50 -0800
Subject: [cfe-dev] vector function return type
In-Reply-To: <aad8390912021834v35ef7164i388e32b6ae9d79fb@mail.gmail.com>
References: <aad8390912021834v35ef7164i388e32b6ae9d79fb@mail.gmail.com>
Message-ID: <f5aa3e9b0912021912i1adf5509qa938bfd9ff5358ec@mail.gmail.com>

On Wed, Dec 2, 2009 at 6:34 PM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> I'm looking at bug 5650 about using vector return types on functions, which
> is kind of difficult, not knowing all the ramifications of the type system.
>
> For example, I need to change the return type of a function declaration, but
> there aren't any accessors for that.? Is that because it's complicated?

It's not ridiculously complicated, but it's messy enough that you'll
want to write a helper method; something like the following should
work (not compiled, but should be approximately correct):
QualType NewResultTy; /* Your new result type */
QualType NewType;
if (const FunctionProtoType* FPT = FD->getType()-->getAs<FunctionProtoType>())
  NewType = Context.getFunctionType(NewResultTy,
FPT->arg_type_begin(), FPT->getNumArgs(), FPT->isVariadic(), 0,
FPT->hasExceptionSpec(), FPT->hasAnyxceptionSpec(),
FPT->getNumExceptions(), FPT->exception_begin(),
FPT->getNoReturnAttr());
else
  NewType = Context.getFunctionTypeNoProto(NewResultType,
FD->getType()->getAs<FunctionType>()->getNoReturnAttr());
FD->setType(NewType);

> Anyway, I've taken a stab at the bug fix, but I'm guessing it's not the
> right approach.? I added a couple of setters to FunctionDecl and
> FunctionType for the return type, not know if this is doable.? In the
> vector_size handler, I don't try to handle all the other types that need
> handling at this point, just wanting to get the vector return types to work
> as a first step.

You can't add a setter to FunctionType because the type system depends
on types being immutable.

-Eli


From rjmccall at apple.com  Wed Dec  2 21:20:47 2009
From: rjmccall at apple.com (John McCall)
Date: Wed, 2 Dec 2009 19:20:47 -0800
Subject: [cfe-dev] vector function return type
In-Reply-To: <aad8390912021834v35ef7164i388e32b6ae9d79fb@mail.gmail.com>
References: <aad8390912021834v35ef7164i388e32b6ae9d79fb@mail.gmail.com>
Message-ID: <33827D64-A6A3-4D31-A533-2847DADF2008@apple.com>


On Dec 2, 2009, at 6:34 PM, John Thompson wrote:

> I'm looking at bug 5650 about using vector return types on functions, which is kind of difficult, not knowing all the ramifications of the type system.
>  
> For example, I need to change the return type of a function declaration, but there aren't any accessors for that.  Is that because it's complicated?

Yes.  Among other problems, the redeclaration logic will be completely wrong if you take a fully-formed function declaration and change its type.  You really need to find the attribute before building the declaration, or at least before doing redeclaration checks on it.

Meta-question:  are we sure we want to allow this syntax?  Is this a gcc compatibility issue?  Because gcc's habit of pushing attributes from decls to random component types is already really bogus, and I'm hesitant to add to that when there's a perfectly reasonable solution (typedef the vector type) already.

> For example, since the QualType can apparently point to something, is that allocated storage, such that it would leak if I just assigned to it, or is the memory managed elsewhere?  Sorry, I probably should just study it some more.

Types are immutable;  the ASTContext uniques types based on their components, and then the type object lives forever as part of the ASTContext.  So you don't have to worry about leaking memory, but you also won't be able to naively modify types like this.

John.

From daniel at zuster.org  Wed Dec  2 22:10:49 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Wed, 2 Dec 2009 20:10:49 -0800
Subject: [cfe-dev] clang-cc option change
Message-ID: <6a8523d60912022010w51bf360ah2647449eb10714d3@mail.gmail.com>

Hi all,

As part of clang / clang-cc integration, I am about to switch clang-cc
to using the new option parsing functionality, and drop the use of
llvm::cl.

This has a few implication you might want to be aware of:
 1. The exact syntax accepted by clang-cc is becoming much stricter,
and follows the clang (slash gcc driver) argument format. The most
noticeable differences:
    a. '-a' cannot automatically be spelled '--a'; if this is desired
it must be explicit in the CC1Options.td file (using an alias).
    b. Options which take arguments don't automatically accept the
'-foo=bar', and this form is never allowed for boolean options. Some
options are still allowed to be spelled as either '-foo bar' or
'-foo=bar', but only because explicit aliases have been defined for
them.

If this fundamentally upsets you, we could change it by making the
option parser more flexible. However, given that this matches how the
driver works, it makes sense to me to have clang and clang -cc1 behave
similarly.

 2. Adding options is now totally different, and unfortunately a bit
more cumbersome. I hope to make it less cumbersome over time, but
until then feel free to swear at me under your breath when you go to
add an option. The reason it is more cumbersome is because we have
more functionality, namely the ability to serialize and deserialize a
CompilerInvocation object to an argument vector.

Previously, adding an option to clang-cc generally meant:
 a. Add an entry in LangOptions or CodeGenOptions or whatever to
persist the value.
 b. Add an llvm::cl option definition.
 c. Add some code in clang-cc.cpp (that code is now in Options.cpp) to
take the llvm::cl value and stuff it into the field from (a).

Now, adding an option to clang-cc (soon to be clang -cc1) looks like:
 a. (same as above)
 b. Add the option in include/clang/Driver/CC1Options.td
 c. Add code to serialize the option in CompilerInvocation.cpp in the
appropriate ParseFooArgs routine. That is, given a LangOptions
structure, create the necessary command line arguments to regenerate
the field. Generally this forces options to be simpler and more
consistent -- if you require some logic be associated with your option
then that logic should be in the Driver, not in clang-cc.
 d. Add code to parse/deserialize the field from an argument vector,
in the appropriate FooToArgs routine. Note that the OptParser library
currently has less support for, say, interpreting enums, than llvm::cl
which is one of the reasons this can be cumbersome.

My eventual hope is to leverage the CC1Options.td file more so that
the serialization / deserialization code is more automatic (and
validated). The idea would be to keep the option definitions separate,
but provide additional information on how they should be mapped onto a
C++ structure. This might also be useful for defining parts of how the
Driver maps command line arguments to Tools.

 - Daniel

From daniel at zuster.org  Thu Dec  3 01:06:02 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Wed, 2 Dec 2009 23:06:02 -0800
Subject: [cfe-dev] clang-cc option change
In-Reply-To: <6a8523d60912022010w51bf360ah2647449eb10714d3@mail.gmail.com>
References: <6a8523d60912022010w51bf360ah2647449eb10714d3@mail.gmail.com>
Message-ID: <6a8523d60912022306k33bdf3f7j5a4d0034815bafed@mail.gmail.com>

An extra point I forgot to make, this also implies that clang-cc no
longer accepts llvm::cl options. I will add -mllvm if there proves to
be a need, but I also plan to fight against it. :)

 - Daniel

On Wed, Dec 2, 2009 at 8:10 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> Hi all,
>
> As part of clang / clang-cc integration, I am about to switch clang-cc
> to using the new option parsing functionality, and drop the use of
> llvm::cl.
>
> This has a few implication you might want to be aware of:
> ?1. The exact syntax accepted by clang-cc is becoming much stricter,
> and follows the clang (slash gcc driver) argument format. The most
> noticeable differences:
> ? ?a. '-a' cannot automatically be spelled '--a'; if this is desired
> it must be explicit in the CC1Options.td file (using an alias).
> ? ?b. Options which take arguments don't automatically accept the
> '-foo=bar', and this form is never allowed for boolean options. Some
> options are still allowed to be spelled as either '-foo bar' or
> '-foo=bar', but only because explicit aliases have been defined for
> them.
>
> If this fundamentally upsets you, we could change it by making the
> option parser more flexible. However, given that this matches how the
> driver works, it makes sense to me to have clang and clang -cc1 behave
> similarly.
>
> ?2. Adding options is now totally different, and unfortunately a bit
> more cumbersome. I hope to make it less cumbersome over time, but
> until then feel free to swear at me under your breath when you go to
> add an option. The reason it is more cumbersome is because we have
> more functionality, namely the ability to serialize and deserialize a
> CompilerInvocation object to an argument vector.
>
> Previously, adding an option to clang-cc generally meant:
> ?a. Add an entry in LangOptions or CodeGenOptions or whatever to
> persist the value.
> ?b. Add an llvm::cl option definition.
> ?c. Add some code in clang-cc.cpp (that code is now in Options.cpp) to
> take the llvm::cl value and stuff it into the field from (a).
>
> Now, adding an option to clang-cc (soon to be clang -cc1) looks like:
> ?a. (same as above)
> ?b. Add the option in include/clang/Driver/CC1Options.td
> ?c. Add code to serialize the option in CompilerInvocation.cpp in the
> appropriate ParseFooArgs routine. That is, given a LangOptions
> structure, create the necessary command line arguments to regenerate
> the field. Generally this forces options to be simpler and more
> consistent -- if you require some logic be associated with your option
> then that logic should be in the Driver, not in clang-cc.
> ?d. Add code to parse/deserialize the field from an argument vector,
> in the appropriate FooToArgs routine. Note that the OptParser library
> currently has less support for, say, interpreting enums, than llvm::cl
> which is one of the reasons this can be cumbersome.
>
> My eventual hope is to leverage the CC1Options.td file more so that
> the serialization / deserialization code is more automatic (and
> validated). The idea would be to keep the option definitions separate,
> but provide additional information on how they should be mapped onto a
> C++ structure. This might also be useful for defining parts of how the
> Driver maps command line arguments to Tools.
>
> ?- Daniel
>


From john.thompson.jtsoftware at gmail.com  Thu Dec  3 09:24:43 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 3 Dec 2009 07:24:43 -0800
Subject: [cfe-dev] vector function return type
In-Reply-To: <33827D64-A6A3-4D31-A533-2847DADF2008@apple.com>
References: <aad8390912021834v35ef7164i388e32b6ae9d79fb@mail.gmail.com>
	<33827D64-A6A3-4D31-A533-2847DADF2008@apple.com>
Message-ID: <aad8390912030724s56ab7f24la95283cf75cf6096@mail.gmail.com>

Thanks, it makes sense.  I'll see if I can put in support for handling this
attribute as part of setting up the initial declaration.

Actually, what I really want is to implement Altivec vector support (i.e.
the "vector" keyword and the associated built-in functions), but I figured
fixing this was a useful stop along the way.

In a previous posting to this list about Altivec support, I was pointed to
the vector_size attribute, and some gcc docs about __vector (it seems we
don't have __vector yet), but I didn't really hear a yea or nay about
putting in "vector" (and "__vector").  Our gcc-based PS3 compiler implements
"vector" directly (i.e. no typedef or #define enabled in altivec.h).  I
understand this will require a look-ahead to see if there is a numeric type
following "vector".  Would it be okay for me to take a crack at doing this?

And looking father ahead, there are some areas where gcc diverges from the
Altivec standard.  Would we want to fix this in Clang too?  (I.e. support
both the gcc form and the standard, hopefully without requiring a new
option?)

Thanks.

-John
On Wed, Dec 2, 2009 at 7:20 PM, John McCall <rjmccall at apple.com> wrote:

>
> On Dec 2, 2009, at 6:34 PM, John Thompson wrote:
>
> > I'm looking at bug 5650 about using vector return types on functions,
> which is kind of difficult, not knowing all the ramifications of the type
> system.
> >
> > For example, I need to change the return type of a function declaration,
> but there aren't any accessors for that.  Is that because it's complicated?
>
> Yes.  Among other problems, the redeclaration logic will be completely
> wrong if you take a fully-formed function declaration and change its type.
>  You really need to find the attribute before building the declaration, or
> at least before doing redeclaration checks on it.
>
> Meta-question:  are we sure we want to allow this syntax?  Is this a gcc
> compatibility issue?  Because gcc's habit of pushing attributes from decls
> to random component types is already really bogus, and I'm hesitant to add
> to that when there's a perfectly reasonable solution (typedef the vector
> type) already.
>
> > For example, since the QualType can apparently point to something, is
> that allocated storage, such that it would leak if I just assigned to it, or
> is the memory managed elsewhere?  Sorry, I probably should just study it
> some more.
>
> Types are immutable;  the ASTContext uniques types based on their
> components, and then the type object lives forever as part of the
> ASTContext.  So you don't have to worry about leaking memory, but you also
> won't be able to naively modify types like this.
>
> 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/20091203/3768440f/attachment-0001.html 

From nicola.gigante at gmail.com  Thu Dec  3 14:56:27 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 3 Dec 2009 21:56:27 +0100
Subject: [cfe-dev] Hello everybody and first question
Message-ID: <C059920A-0864-490E-8826-525C0B4EE80E@gmail.com>

Hello everybody.

I'm new to the list, I've subscribed because I'm looking at the clang source code for fun and learning.

First of all, congratulations, it's a great work!

In my opinion, the best thing to do to learn how clang internals work is to do something concrete, so I've read the TODO file and I saw there are a few jobs that seems simple enough. For example, I read:

More ideas for code modification hints:
  - If no member of a given name is found in a class/struct, search through the names of entities that do exist in the class and suggest the closest candidate. e.g., if I write "DS.setTypeSpecType", it would suggest "DS.SetTypeSpecType" (edit distance = 1).
... others...
  - Change "foo.bar" to "foo->bar" when "foo" is a pointer.

First of all, is the TODO file up-to-date? Then.. Which part of the source code should I look to fix these two points?

Another thing. In the case I could end up with a working patch, how does the clang contribution policy work? Do I have to send the patches to this list, or to someone in particular?

Thank you very much,

Nicola

From nicola.gigante at gmail.com  Thu Dec  3 15:38:41 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 3 Dec 2009 22:38:41 +0100
Subject: [cfe-dev] Hello everybody and first question
In-Reply-To: <521640720912031330i1a140136kd6721290bc7160ea@mail.gmail.com>
References: <C059920A-0864-490E-8826-525C0B4EE80E@gmail.com>
	<521640720912031330i1a140136kd6721290bc7160ea@mail.gmail.com>
Message-ID: <5E1D429A-AB48-45F4-90D7-5E460D70F9C1@gmail.com>


> G'Day and welcome Nicola,
> 
> Its always great to see a new face!
> 
> I'll attempt to try to answer some of your questions promptly here.
> You may send patches to this list for both discussion and development
> of that patch as well as general discussions of clang.
> 'Final' draft patches that are 'commit-ready' tend to end up on cfe-commits at .
> 
> I'm not sure, myself, if the TODO list is up to date, I hope it is.
> Please do post your patch here in any case, it may well interest
> others or inspire a new approach or discussion. Also, note that there
> is a few simple bugs that could be fixed in the bug tracker if your
> 'job hunting' so to speak, so that's a good place to look also.
> 
> Here is a formal doc that explains dev policy stuff;
> http://llvm.org/docs/DeveloperPolicy.html
> 
> Hope this helps,
> Cheers,
> Edward.


Thank you :) Another question: My long-term goal is to work on C++ support. To do this, I think I'll need some reference about the exact language syntax, but I don't know how and where to get the C++ standard reference. I suppose that because they're ISO/ANSI standards, the official papers are not free, are they?

Thank you,

Nicola

From mrs at apple.com  Thu Dec  3 16:15:42 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 3 Dec 2009 14:15:42 -0800
Subject: [cfe-dev] Hello everybody and first question
In-Reply-To: <5E1D429A-AB48-45F4-90D7-5E460D70F9C1@gmail.com>
References: <C059920A-0864-490E-8826-525C0B4EE80E@gmail.com>
	<521640720912031330i1a140136kd6721290bc7160ea@mail.gmail.com>
	<5E1D429A-AB48-45F4-90D7-5E460D70F9C1@gmail.com>
Message-ID: <2F96D2C6-8A26-4EDB-8640-D040EE5F32BE@apple.com>

On Dec 3, 2009, at 1:38 PM, Nicola Gigante wrote:
> Thank you :) Another question: My long-term goal is to work on C++ support. To do this, I think I'll need some reference about the exact language syntax, but I don't know how and where to get the C++ standard reference. I suppose that because they're ISO/ANSI standards, the official papers are not free, are they?

http://www.open-std.org/jtc1/sc22/wg21/

In there you can find a working paper I bet...  maybe something like: 

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf

From sebastian.redl at getdesigned.at  Thu Dec  3 17:18:20 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Fri, 04 Dec 2009 00:18:20 +0100
Subject: [cfe-dev] Hello everybody and first question
In-Reply-To: <2F96D2C6-8A26-4EDB-8640-D040EE5F32BE@apple.com>
References: <C059920A-0864-490E-8826-525C0B4EE80E@gmail.com>	<521640720912031330i1a140136kd6721290bc7160ea@mail.gmail.com>	<5E1D429A-AB48-45F4-90D7-5E460D70F9C1@gmail.com>
	<2F96D2C6-8A26-4EDB-8640-D040EE5F32BE@apple.com>
Message-ID: <4B18473C.5030604@getdesigned.at>

Mike Stump wrote:
> On Dec 3, 2009, at 1:38 PM, Nicola Gigante wrote:
>   
>> Thank you :) Another question: My long-term goal is to work on C++ support. To do this, I think I'll need some reference about the exact language syntax, but I don't know how and where to get the C++ standard reference. I suppose that because they're ISO/ANSI standards, the official papers are not free, are they?
>>     
>
> http://www.open-std.org/jtc1/sc22/wg21/
>
> In there you can find a working paper I bet...  maybe something like: 
>
>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3000.pdf
>   
This is the latest draft of C++0x, indeed.
To get the current official standard, (C++03), you can go to ISO's or
ANSI's web store. Due to some failure in coordination that I cannot
begin to fathom, ANSI offers it for a far more reasonable price than ISO.

Sebastian

From dgregor at apple.com  Thu Dec  3 20:25:38 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 3 Dec 2009 18:25:38 -0800
Subject: [cfe-dev] Hello everybody and first question
In-Reply-To: <C059920A-0864-490E-8826-525C0B4EE80E@gmail.com>
References: <C059920A-0864-490E-8826-525C0B4EE80E@gmail.com>
Message-ID: <A9CC7116-C9C2-4218-8DC0-9612CCAD7FC6@apple.com>


On Dec 3, 2009, at 12:56 PM, Nicola Gigante wrote:

> Hello everybody.
> 
> I'm new to the list, I've subscribed because I'm looking at the clang source code for fun and learning.

Welcome!

> First of all, congratulations, it's a great work!
> 
> In my opinion, the best thing to do to learn how clang internals work is to do something concrete, so I've read the TODO file and I saw there are a few jobs that seems simple enough. For example, I read:
> 
> More ideas for code modification hints:
>  - If no member of a given name is found in a class/struct, search through the names of entities that do exist in the class and suggest the closest candidate. e.g., if I write "DS.setTypeSpecType", it would suggest "DS.SetTypeSpecType" (edit distance = 1).
> ... others...
>  - Change "foo.bar" to "foo->bar" when "foo" is a pointer.
> 
> First of all, is the TODO file up-to-date?

Mostly, yes.

> Then.. Which part of the source code should I look to fix these two points?

Both of them would get implemented in the function Sema::LookupMemberExpr, which is in lib/Sema/SemaExpr.cpp.

The second one is probably easier, because it will be a localized change, mostly likely around line 2600 (where we have the "if (IsArrow)" check.

> Another thing. In the case I could end up with a working patch, how does the clang contribution policy work? Do I have to send the patches to this list, or to someone in particular?


We prefer that patches be sent to the cfe-commits mailing list, unless you think that the patch does something fundamentally new or different from what's already in Clang: in that case, we like to discuss ideas here on cfe-dev first.

	- Doug

From xuzhongxing at gmail.com  Thu Dec  3 20:49:12 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Fri, 4 Dec 2009 10:49:12 +0800
Subject: [cfe-dev]  About BlockDecl
Message-ID: <5400aeb80912031849y7592b24dy3c85c81cfe032c98@mail.gmail.com>

Hi,

I have two questions about BlockDecl.

1. Is it possible to distinguish the following decls in AST:

^ void (void) {  };

^ (void) {};

^{};

2. When is BlockDeclRefExpr used?

Thanks.

From dgregor at apple.com  Fri Dec  4 00:30:11 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 3 Dec 2009 22:30:11 -0800
Subject: [cfe-dev] Clang Parses Clang
Message-ID: <BB9616D8-38F7-428C-8CB1-99883E12CC62@apple.com>

I'm happy to announce that Clang's C++ support has improved to the point where it can now parse all of its own header (.hpp) and source (.cpp) files. There is still much more work to do for C++---in semantic analysis, code generation, robustness, beautiful diagnostics, performance, etc.---but this is a great milestone, and everyone involved in Clang should give themselves a little pat on the back. Congrats!

Next up: parsing all of LLVM!

	- Doug

From kremenek at apple.com  Fri Dec  4 01:07:17 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Thu, 3 Dec 2009 23:07:17 -0800
Subject: [cfe-dev] About BlockDecl
In-Reply-To: <5400aeb80912031849y7592b24dy3c85c81cfe032c98@mail.gmail.com>
References: <5400aeb80912031849y7592b24dy3c85c81cfe032c98@mail.gmail.com>
Message-ID: <E343C2D5-5039-49CA-B967-901604A699CC@apple.com>


On Dec 3, 2009, at 6:49 PM, Zhongxing Xu wrote:

> Hi,
> 
> I have two questions about BlockDecl.
> 
> 1. Is it possible to distinguish the following decls in AST:
> 
> ^ void (void) {  };
> 
> ^ (void) {};
> 
> ^{};

Hmm.  It doesn't look like BlockDecl currently doesn't store enough source information to distinguish these cases, although I may be wrong.

> 2. When is BlockDeclRefExpr used?

It's used within a block to refer to a "captured" variable from outside the block.  From SemaExpr.cpp:

  // If the identifier reference is inside a block, and it refers to a value
  // that is outside the block, create a BlockDeclRefExpr instead of a
  // DeclRefExpr.  This ensures the value is treated as a copy-in snapshot when
  // the block is formed.
  //

For example:

void foo(void) {
  int x = 0;
  ^{ x + 1; }();
}

The 'x' within the block would be BlockDeclRefExpr, as it refers to a "captured" variable outside the block.  By default, captured variables are literally copied when the block is created, but if a __block annotation precedes the declaration, the variable is captured by reference.  e.g.:

void bar(void) {
  __block int x = 0;
 ^{ x = x + 1; }();
 }

Here 'x' in bar is literally modified by the block.

From xuzhongxing at gmail.com  Fri Dec  4 01:25:15 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Fri, 4 Dec 2009 15:25:15 +0800
Subject: [cfe-dev] About BlockDecl
In-Reply-To: <E343C2D5-5039-49CA-B967-901604A699CC@apple.com>
References: <5400aeb80912031849y7592b24dy3c85c81cfe032c98@mail.gmail.com>
	<E343C2D5-5039-49CA-B967-901604A699CC@apple.com>
Message-ID: <5400aeb80912032325t2a5fc1cbx2a404a79ba8550dc@mail.gmail.com>

Thanks. That's clear.

2009/12/4 Ted Kremenek <kremenek at apple.com>:
>
> On Dec 3, 2009, at 6:49 PM, Zhongxing Xu wrote:
>
>> Hi,
>>
>> I have two questions about BlockDecl.
>>
>> 1. Is it possible to distinguish the following decls in AST:
>>
>> ^ void (void) { ?};
>>
>> ^ (void) {};
>>
>> ^{};
>
> Hmm. ?It doesn't look like BlockDecl currently doesn't store enough source information to distinguish these cases, although I may be wrong.
>
>> 2. When is BlockDeclRefExpr used?
>
> It's used within a block to refer to a "captured" variable from outside the block. ?From SemaExpr.cpp:
>
> ?// If the identifier reference is inside a block, and it refers to a value
> ?// that is outside the block, create a BlockDeclRefExpr instead of a
> ?// DeclRefExpr. ?This ensures the value is treated as a copy-in snapshot when
> ?// the block is formed.
> ?//
>
> For example:
>
> void foo(void) {
> ?int x = 0;
> ?^{ x + 1; }();
> }
>
> The 'x' within the block would be BlockDeclRefExpr, as it refers to a "captured" variable outside the block. ?By default, captured variables are literally copied when the block is created, but if a __block annotation precedes the declaration, the variable is captured by reference. ?e.g.:
>
> void bar(void) {
> ?__block int x = 0;
> ?^{ x = x + 1; }();
> ?}
>
> Here 'x' in bar is literally modified by the block.


From daniel at zuster.org  Fri Dec  4 02:03:31 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 4 Dec 2009 00:03:31 -0800
Subject: [cfe-dev] Clang Parses Clang
In-Reply-To: <BB9616D8-38F7-428C-8CB1-99883E12CC62@apple.com>
References: <BB9616D8-38F7-428C-8CB1-99883E12CC62@apple.com>
Message-ID: <6a8523d60912040003h60f1fe38jba7fcd3d362e7280@mail.gmail.com>

This is totally awesome, congratulations Doug et al.!

 - Daniel

On Thu, Dec 3, 2009 at 10:30 PM, Douglas Gregor <dgregor at apple.com> wrote:
> I'm happy to announce that Clang's C++ support has improved to the point where it can now parse all of its own header (.hpp) and source (.cpp) files. There is still much more work to do for C++---in semantic analysis, code generation, robustness, beautiful diagnostics, performance, etc.---but this is a great milestone, and everyone involved in Clang should give themselves a little pat on the back. Congrats!
>
> Next up: parsing all of LLVM!
>
> ? ? ? ?- Doug
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From nicola.gigante at gmail.com  Fri Dec  4 08:24:29 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Fri, 4 Dec 2009 15:24:29 +0100
Subject: [cfe-dev] Hello everybody and first question
In-Reply-To: <A9CC7116-C9C2-4218-8DC0-9612CCAD7FC6@apple.com>
References: <C059920A-0864-490E-8826-525C0B4EE80E@gmail.com>
	<A9CC7116-C9C2-4218-8DC0-9612CCAD7FC6@apple.com>
Message-ID: <8A4C6C33-233E-4469-9C37-79BBE8FFAD7D@gmail.com>

Thank you everybody for the replies :)

Nicola

From daniel at zuster.org  Fri Dec  4 10:20:16 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 4 Dec 2009 08:20:16 -0800
Subject: [cfe-dev] RFC: Integrating clang-cc functionality into clang
	(the driver)
In-Reply-To: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>
References: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>
Message-ID: <6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>

Hello again,

All the major pieces of the clang / clang-cc integration project are
now in place, which means its time to put them to work! :)

The next step is to eliminate the clang-cc binary. I am going to do
this pretty soon, but I wanted to give people a brief heads up in case
it is likely to conflict with some changes in flight. Please let me
know if you think this will disrupt you.

This is (the disruptive part of) what is going to happen:
 1. clang will get the -cc1 mode, which will be equivalent to calling
clang-cc, and clang will recursively invoke itself (for now). clang
link will become very slow. :/
 2. All the tests are going to be rewritten to use 'clang -cc1'
instead of 'clang-cc'.
 3. clang-cc will be removed.

Here are some comments on what actually has been done, if you are interested:

On Tue, Nov 3, 2009 at 1:07 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> Hi all,
>
> I've been thinking lately about how we can push forward with our goal of
> integrating the 'clang-cc' functionality into the 'clang' executable, so that we
> have a single compiler binary. This will also unblock future work on clang APIs,
> and hopefully make it easier to support new interesting uses of clang.
>
> Heres my proposal:
>
> --
>
> Goals
> --
>
> ?1. Make it easier to build clang based tools (from an API perspective).

We still have a ways to go, but I think the new CompilerInstance class
at least helps with this.

> ?2. Avoid unnecessary fork/exec of clang-cc.
> ? ?a. Makes it easier to debug!
> ? ?b. Make driver / compiler interaction more obviously a private
> implementation
> ? ? ? detail.

This will be an easy incremental change once the -cc1 mode is in, and
shouldn't be disruptive. Although you won't have to cut-and-paste for
compiler crashes, which might make you happy. :)

> Non-Goals
> --
>
> ?1. Add a general purpose mechanism for extending 'clang' (e.g., a plugin
> ?model). This work will make that easier, however.

This is still a non-goal, but I did add plugin support to 'clang-cc',
for people interested in quickly writing a new ASTConsumer and
plugging it in. It doesn't work that well yet given the static
constructors in the backend (for example, pass manager complaining
about passes being registered multiple times).

> Proposal (user level)
> --
>
> ?1. Driver gets a new option -cc1, which must be the leading argument (after any
> ?-ccc arguments, but those are "internal" and not supposed to be used by users
> ?anyway). This is a "mode", the remaining arguments will be processed "like"
> ?clang-cc arguments. This is just for debuggability, and for use in -v or -###.
>
> ?In practice, the arguments will be processed by hand or by reusing the driver
> ?argument parsing functionality instead of using LLVM's command line library.

The driver argument parsing got reused, and TableGenified in the process.

> ?2. 'clang' gets a new option -no-integrated-cc1 which would just execute
> ?'clang' recursively passing the -cc1 argument. Primarily only for testing,
> ?users shouldn't have a good reason to use this.
>
> ?3. We'll take some steps to still be friendly if clang crashes (currently the
> ?driver tries to at least print a canonical "error: clang-cc failed" type of
> ?message).

This will be done once we drop fork/exec.

>
> Proposal (implementation)
> --
>
> ?1. There will be a new class CompilerInstance (suggestions for a better name
> ?welcome) which holds all of the state needed for running Clang. That is, this
> ?will wrap the source manager, the file manager, the preprocessor factory, the
> ?AST context, the AST consumer, and all that horrible stuff. This will probably
> ?actually be constructed via a builder.

Done.

> ?2. Internally there will be a CompilerInvocation object which maintains the
> ?various bits of state that forms a single invocation of clang-cc (include
> ?paths, target options, triple, code generation options, etc.).
>
> ? a. The CompilerInvocation object will have two important methods, the first
> ? converts the invocation into a list of 'clang -cc1' arguments. The second
> ? "executes" the invocation and returns a CompilerInstance instance.

Done.

> ? b. The Driver will get a new CompilerJob class which just wraps a
> ? CompilerInvocation. The Driver's Clang tool implementation will be changed to
> ? construct an instance of this object instead of constructing a list of
> ? arguments. This job will take care of running the clang compiler in/out-of
> ? process depending on -no-integrated-cc1, but otherwise is just an adaptor for
> ? CompilerInvocation.

Not done.

> ? c. There will be a method to turn a 'clang -cc1' argument list into a
> ? CompilerInvocation object.

Done.

> ?3. The Driver will get a new API for parsing a "gcc-like" argument list which
> ?corresponds to a single "compile only" task (-fsyntax-only, -S, etc.), and
> ?returns a CompilerJob. This API will return an error for argument vectors which
> ?would do something more complicated, for example executing multiple
> ?compilations or running the linker or assembler.

Not done, but this turned out to not really be necessary for the
functionality I wanted (in ASTUnit). It would still be nice from a
code cleanliness perspective.

> ?4. Move "standard" tests to use 'clang -cc1' instead of 'clang-cc'.

That's what this email is about!

> The Future of clang-cc
> --
>
> clang-cc is kind of a mess, so at least initially I'd rather just move the
> driver and appropriate tests to using the 'clang' executable. Once that's done
> we can reevaluate and see what the next step is. One option is to keep clang-cc
> around as a dumping/play ground for tools or other features that don't fit into
> the "compiler" model of functionality. Another option is to extend 'clang' to
> support the main features of clang-cc we care about (i.e., the ones we test) and
> move everything else into separate tools (which would probably only be
> optionally built -- these would amount to examples).

I ended up deciding I didn't want to leave clang-cc as a wasteland,
and so it got refactored along the way. It is now largely just the
setup of a CompilerInstance object.

 - Daniel


From john.thompson.jtsoftware at gmail.com  Fri Dec  4 10:36:48 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Fri, 4 Dec 2009 08:36:48 -0800
Subject: [cfe-dev] vector function return type
In-Reply-To: <aad8390912030724s56ab7f24la95283cf75cf6096@mail.gmail.com>
References: <aad8390912021834v35ef7164i388e32b6ae9d79fb@mail.gmail.com>
	<33827D64-A6A3-4D31-A533-2847DADF2008@apple.com>
	<aad8390912030724s56ab7f24la95283cf75cf6096@mail.gmail.com>
Message-ID: <aad8390912040836q722caf77p196d6b979a58a141@mail.gmail.com>

Here's another go at it (fix for bug 5650).  It looks like the code was
already in place for handling attributes for types before the declaration
was finalized.  I basically just hacked up HandleVectorSizeAttr and moved it
to be called from ProcessTypeAttributeList instead of ProcessDeclAttribute.

I also revised PrintVector in the type printer to put the vector_size
attribute first, and revised the test in Sema/vector-init.c.

Is anything else needed for this?
-John
On Thu, Dec 3, 2009 at 7:24 AM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Thanks, it makes sense.  I'll see if I can put in support for handling this
> attribute as part of setting up the initial declaration.
>
> Actually, what I really want is to implement Altivec vector support (i.e.
> the "vector" keyword and the associated built-in functions), but I figured
> fixing this was a useful stop along the way.
>
> In a previous posting to this list about Altivec support, I was pointed to
> the vector_size attribute, and some gcc docs about __vector (it seems we
> don't have __vector yet), but I didn't really hear a yea or nay about
> putting in "vector" (and "__vector").  Our gcc-based PS3 compiler implements
> "vector" directly (i.e. no typedef or #define enabled in altivec.h).  I
> understand this will require a look-ahead to see if there is a numeric type
> following "vector".  Would it be okay for me to take a crack at doing this?
>
> And looking father ahead, there are some areas where gcc diverges from the
> Altivec standard.  Would we want to fix this in Clang too?  (I.e. support
> both the gcc form and the standard, hopefully without requiring a new
> option?)
>
> Thanks.
>
> -John
>   On Wed, Dec 2, 2009 at 7:20 PM, John McCall <rjmccall at apple.com> wrote:
>
>>
>> On Dec 2, 2009, at 6:34 PM, John Thompson wrote:
>>
>> > I'm looking at bug 5650 about using vector return types on functions,
>> which is kind of difficult, not knowing all the ramifications of the type
>> system.
>> >
>> > For example, I need to change the return type of a function declaration,
>> but there aren't any accessors for that.  Is that because it's complicated?
>>
>> Yes.  Among other problems, the redeclaration logic will be completely
>> wrong if you take a fully-formed function declaration and change its type.
>>  You really need to find the attribute before building the declaration, or
>> at least before doing redeclaration checks on it.
>>
>> Meta-question:  are we sure we want to allow this syntax?  Is this a gcc
>> compatibility issue?  Because gcc's habit of pushing attributes from decls
>> to random component types is already really bogus, and I'm hesitant to add
>> to that when there's a perfectly reasonable solution (typedef the vector
>> type) already.
>>
>> > For example, since the QualType can apparently point to something, is
>> that allocated storage, such that it would leak if I just assigned to it, or
>> is the memory managed elsewhere?  Sorry, I probably should just study it
>> some more.
>>
>> Types are immutable;  the ASTContext uniques types based on their
>> components, and then the type object lives forever as part of the
>> ASTContext.  So you don't have to worry about leaking memory, but you also
>> won't be able to naively modify types like this.
>>
>> 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/20091204/953cb70c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vecreturn1.patch
Type: application/octet-stream
Size: 9436 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091204/953cb70c/attachment-0001.obj 

From nicola.gigante at gmail.com  Fri Dec  4 10:37:05 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Fri, 4 Dec 2009 17:37:05 +0100
Subject: [cfe-dev] My first patch to clang
Message-ID: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>

Hello,

as promised I've started to look at how clang works under the hood.

My first "kid job" was to implement a simple diagnostic improvement that suggests to use -> instead of . if the base expression is a pointer. You find the patch attached.

In the last mail, Douglas told me to send trivial patches to cfe-commits but I've prefered to post it here because it's the first one and I'm unsure about a couple of things.

1) Have I chosen the right locations for the caret, the range and the substitution? The original error used to put the caret _after_ the dot, but I put the caret _at_ the dot, because I think it's more reasonable.

2) Is it ok to add a new diagnostic string in this case? Are the string and the enum name appropriate?

3) Any other hint?

Thanks,

Nicola

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

From edwintorok at gmail.com  Fri Dec  4 10:50:41 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Fri, 04 Dec 2009 18:50:41 +0200
Subject: [cfe-dev] RFC: Integrating clang-cc functionality into clang
 (the driver)
In-Reply-To: <6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>
References: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>
	<6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>
Message-ID: <4B193DE1.7000306@gmail.com>

On 2009-12-04 18:20, Daniel Dunbar wrote:
> Hello again,
>
> All the major pieces of the clang / clang-cc integration project are
> now in place, which means its time to put them to work! :)
>   

Hi,

So can I now invoke the driver directly (after forking, in case it
crashes),
without the need for execve(), and have the ability to turn all the
clang-cc commandline flags on/off?
Is there a way now to get diagnostics directly, without the need to
redirect/parse the output?

Also will cl::ParseCommandLineOptions still work for LLVM commandline
options?

I am currently using some rather low-level switches for clang-cc, so I
might as well ask now whether these are going away in the future or not:
-ffreestanding -nostdinc -disable-free -fdiagnostics-show-option
-fmessage-length=80
-fcolor-diagnostics -triple clambc-generic-generic -include bytecode.h
-Wall -warn-dead-stores  -warn-security-syntactic -analyzer-eagerly-assume
-v -g -E -S

Also I've been experimenting at some point with writing a simple editor
that uses clang for syntax highlighting/completion.
There were 2 issues:
 - creating the Preprocessor object involved setting lot of language
related stuff, like implicitint, accesscontrol, bool support, and so on.
Is there a way to just tell it to create with the language defaults that
the clang driver would use? (and eventually tell it about
-std=c99, and it automatically sets up whatever clang sets up for c99).

- This isn't necesarely related to your driver work, but I didn't see
any support for reusing previous parse results, like reparsing only the
portion of the
file/membuffer that changed. Can that somehow be accomplished with the
new driver infrastructure? (i.e. tell it that you've previously compiled
this file
with same driver, and now you only want to reparse/rebuild the AST for
the changed part).

Best regards,
--Edwin

From daniel at zuster.org  Fri Dec  4 11:35:10 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 4 Dec 2009 09:35:10 -0800
Subject: [cfe-dev] RFC: Integrating clang-cc functionality into clang
	(the driver)
In-Reply-To: <4B193DE1.7000306@gmail.com>
References: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>
	<6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>
	<4B193DE1.7000306@gmail.com>
Message-ID: <6a8523d60912040935ncf3b5c4ic4fcbcbdbf6fe6ac@mail.gmail.com>

2009/12/4 T?r?k Edwin <edwintorok at gmail.com>:
> On 2009-12-04 18:20, Daniel Dunbar wrote:
>> Hello again,
>>
>> All the major pieces of the clang / clang-cc integration project are
>> now in place, which means its time to put them to work! :)
>>
>
> Hi,
>
> So can I now invoke the driver directly (after forking, in case it
> crashes),
> without the need for execve(), and have the ability to turn all the
> clang-cc commandline flags on/off?

Yes. Look at ASTUnit::LoadFromSource for example.

> Is there a way now to get diagnostics directly, without the need to
> redirect/parse the output?

Yes.

> Also will cl::ParseCommandLineOptions still work for LLVM commandline
> options?

It works, but it isn't called by default. We could add an -mllvm for
clang-cc for this, although I'd rather not.

> I am currently using some rather low-level switches for clang-cc, so I
> might as well ask now whether these are going away in the future or not:
> -ffreestanding -nostdinc -disable-free -fdiagnostics-show-option
> -fmessage-length=80
> -fcolor-diagnostics -triple clambc-generic-generic -include bytecode.h
> -Wall -warn-dead-stores ?-warn-security-syntactic -analyzer-eagerly-assume
> -v -g -E -S

No, although it would be better for you to use the driver to construct
a CompilerInvocation, and then tweak the resulting object. That way
you are insulated from changes to the clang/clang
-cc1/CompilerInvocation API.

> Also I've been experimenting at some point with writing a simple editor
> that uses clang for syntax highlighting/completion.
> There were 2 issues:
> ?- creating the Preprocessor object involved setting lot of language
> related stuff, like implicitint, accesscontrol, bool support, and so on.
> Is there a way to just tell it to create with the language defaults that
> the clang driver would use? (and eventually tell it about
> -std=c99, and it automatically sets up whatever clang sets up for c99).

You can do this easily now via CompilerInvocation and
CompilerInstance. You can look at how the FrontendAction wrapper
implements this, for example.

> - This isn't necesarely related to your driver work, but I didn't see
> any support for reusing previous parse results, like reparsing only the
> portion of the
> file/membuffer that changed. Can that somehow be accomplished with the
> new driver infrastructure? (i.e. tell it that you've previously compiled
> this file
> with same driver, and now you only want to reparse/rebuild the AST for
> the changed part).

This doesn't really have anything to do with the driver, and we don't
have the underlying feature support for this.

It's great to hear someone is working on this kind of stuff, please
consider packing your work up as an example we can include with clang!

 - Daniel

> Best regards,
> --Edwin
>


From john.thompson.jtsoftware at gmail.com  Fri Dec  4 13:55:34 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Fri, 4 Dec 2009 11:55:34 -0800
Subject: [cfe-dev] Attribute position in parsing class member function
	declarations
In-Reply-To: <81D17FCC-ED96-4ACF-9F3D-1E3024879D01@apple.com>
References: <aad8390911191944l698811d0k11ffd49784567ccb@mail.gmail.com>
	<4B06154A.1080903@gmail.com>
	<aad8390911192023ie209922xfe1210cf02473388@mail.gmail.com>
	<aad8390911240742p72c2af87i1cd2012c8f465298@mail.gmail.com>
	<3C860E69-A767-4BA2-B545-369858BA3B38@apple.com>
	<aad8390911251513p51a30a26xa7acffd54ec3f4da@mail.gmail.com>
	<aad8390911251556t4765d789t17fc2d59af1d4b4b@mail.gmail.com>
	<81D17FCC-ED96-4ACF-9F3D-1E3024879D01@apple.com>
Message-ID: <aad8390912041155p35f31b1dx698268a1db941484@mail.gmail.com>

Doug,

Sorry, I missed noticing your response.

I'm not sure what to do here.  The Clang docs (
http://clang-analyzer.llvm.org/annotations.html#attr_cf_returns_retained)
note that as a Clang-specific attribute.  Do you mean that we should put out
a warning if some more strict standard mode is used, or that there should be
a warning unless clang-specific attributes are explicitly enabled by some
new option?  Or should the test use some sort of "#if
__has_feature(attribute_cf_returns_retained)" conditional?  Or is the
attribute not allowed after the function declation?   Please instruct.
-John
On Wed, Nov 25, 2009 at 4:09 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
>  On Nov 25, 2009, at 3:56 PM, John Thompson wrote:
>
>  I'm not sure this is optimal, but it seems to fix Bug 5605.
>
>
> The parsing is fine, but this is missing some kind of diagnostic, because
> GCC rejects the test case:
>
>  blackthorn:~ dgregor$ gcc t.c
> t.c:3: warning: ?cf_returns_retained? attribute directive ignored
> t.c:3: error: expected ?,? or ?;? before ?{? token
> blackthorn:~ dgregor$ g++ t.c
> t.c:2: error: attributes are not allowed on a function-definition
>
> - Doug
>
>
>  -John
>
> On Wed, Nov 25, 2009 at 3:13 PM, John Thompson <
> john.thompson.jtsoftware at gmail.com> wrote:
>
>> Thanks.
>>
>> >Any chance you're also interested in tackling the related PR here?
>>
>> Sure.  I thought it was the same issue, but I guess it's a different code
>> path.  I'm working on it.
>>
>> -John
>> --
>> John Thompson
>> John.Thompson.JTSoftware at gmail.com
>>
>> <attr_pos2.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091204/471e8b67/attachment.html 

From rideau3 at gmail.com  Fri Dec  4 14:40:28 2009
From: rideau3 at gmail.com (Sean Hunt)
Date: Fri, 04 Dec 2009 13:40:28 -0700
Subject: [cfe-dev] Hitting LexIdentifier with a minor performance hit
Message-ID: <4B1973BC.7050406@gmail.com>

Hey,

I'd like to split LexIdentifier into two functions so that the actual 
identifier lexing logic can be reused for user-defined literal suffixes. 
Since this is a change to the lexing code that will probably have a 
negative performance impact, however slight (one function call of 
overhead per identifier is added; one goto is removed per "nasty" 
identifier (a \, $, or ? is present)), I wanted to check it by first.

The effective change is that the literal lexing code will be able to use 
LexIdentifierInternal to parse the suffix when I add that in.

Sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lexidentifier.patch
Type: text/x-diff
Size: 4451 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091204/bd0bc17d/attachment.bin 

From rjmccall at apple.com  Fri Dec  4 15:20:27 2009
From: rjmccall at apple.com (John McCall)
Date: Fri, 4 Dec 2009 13:20:27 -0800
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
Message-ID: <B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>


On Dec 4, 2009, at 8:37 AM, Nicola Gigante wrote:

> Hello,
> 
> as promised I've started to look at how clang works under the hood.
> 
> My first "kid job" was to implement a simple diagnostic improvement that suggests to use -> instead of . if the base expression is a pointer. You find the patch attached.

Great idea!  We have some similar-in-concept diagnostics/fixits, but not this one specifically.

I see a few issues with this patch, mostly minor.

The first is that we like to have reasonably high confidence in our suggestions.  There are plenty of pointer base types where changing '.' into '->' won't actually help;  for example, int*, struct foo**, etc.  We shouldn't recommend using '->' unless the base is specifically a pointer to a record type.

The second is that fixits should be aligned with error-recovery whenever possible.  In this case, that means that if we're doing to give a fixit for transforming the '.' into the '->', we should then proceed to do the member lookup, build the expression, etc. as if the user had typed '->'.  It looks like you can make that work very easily:  just (1) pass IsArrow to LookupMemberExpr by reference instead of by value, (2) try to diagnose this error *before* the block in LookupMemberExpr that calls LookupMemberInRecord, and (3) set IsArrow = true when you diagnose.

> In the last mail, Douglas told me to send trivial patches to cfe-commits but I've prefered to post it here because it's the first one and I'm unsure about a couple of things.
> 
> 1) Have I chosen the right locations for the caret, the range and the substitution? The original error used to put the caret _after_ the dot, but I put the caret _at_ the dot, because I think it's more reasonable.

Your locations look good.  Pointing the caret at the operator is fine in this case, since the presumed error is with the operator, not with the member or the base expression.

You should test with -fixit to make sure your suggestion actually works.

> 2) Is it ok to add a new diagnostic string in this case? Are the string and the enum name appropriate?

They look fine.

Thanks!

John.

From rjmccall at apple.com  Fri Dec  4 15:32:53 2009
From: rjmccall at apple.com (John McCall)
Date: Fri, 4 Dec 2009 13:32:53 -0800
Subject: [cfe-dev] vector function return type
In-Reply-To: <aad8390912040836q722caf77p196d6b979a58a141@mail.gmail.com>
References: <aad8390912021834v35ef7164i388e32b6ae9d79fb@mail.gmail.com>
	<33827D64-A6A3-4D31-A533-2847DADF2008@apple.com>
	<aad8390912030724s56ab7f24la95283cf75cf6096@mail.gmail.com>
	<aad8390912040836q722caf77p196d6b979a58a141@mail.gmail.com>
Message-ID: <4FE430F3-E104-4D75-8F11-2ACF39DC5FF5@apple.com>

On Dec 4, 2009, at 8:36 AM, John Thompson wrote:

> Here's another go at it (fix for bug 5650).  It looks like the code was already in place for handling attributes for types before the declaration was finalized.  I basically just hacked up HandleVectorSizeAttr and moved it to be called from ProcessTypeAttributeList instead of ProcessDeclAttribute.
>  
> I also revised PrintVector in the type printer to put the vector_size attribute first, and revised the test in Sema/vector-init.c.
>  
> Is anything else needed for this?


Looks good to me!  Feel free to commit whenever you're ready.

Please reference the PR number in the test case (and your commit message).

John.

From clattner at apple.com  Fri Dec  4 17:06:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 4 Dec 2009 15:06:46 -0800
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
Message-ID: <3E01FDFF-594F-478D-8350-6EFC436826EA@apple.com>


On Dec 4, 2009, at 1:20 PM, John McCall wrote:

>
> On Dec 4, 2009, at 8:37 AM, Nicola Gigante wrote:
>
>> Hello,
>>
>> as promised I've started to look at how clang works under the hood.
>>
>> My first "kid job" was to implement a simple diagnostic improvement  
>> that suggests to use -> instead of . if the base expression is a  
>> pointer. You find the patch attached.
>
> Great idea!  We have some similar-in-concept diagnostics/fixits, but  
> not this one specifically.
>
> I see a few issues with this patch, mostly minor.
>
> The first is that we like to have reasonably high confidence in our  
> suggestions.  There are plenty of pointer base types where changing  
> '.' into '->' won't actually help;  for example, int*, struct foo**,  
> etc.  We shouldn't recommend using '->' unless the base is  
> specifically a pointer to a record type.

"pointer to a record type for which the field would be valid".  We  
might as well test that the field makes sense as well.

Thanks again for working on this, it's great to get this enhancement,

-Chris

From dgregor at apple.com  Fri Dec  4 18:46:21 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Fri, 4 Dec 2009 16:46:21 -0800
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <3E01FDFF-594F-478D-8350-6EFC436826EA@apple.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
	<3E01FDFF-594F-478D-8350-6EFC436826EA@apple.com>
Message-ID: <46F9811B-E329-4391-AB03-AE8C885F3752@apple.com>


On Dec 4, 2009, at 3:06 PM, Chris Lattner wrote:

>
> On Dec 4, 2009, at 1:20 PM, John McCall wrote:
>
>>
>> On Dec 4, 2009, at 8:37 AM, Nicola Gigante wrote:
>>
>>> Hello,
>>>
>>> as promised I've started to look at how clang works under the hood.
>>>
>>> My first "kid job" was to implement a simple diagnostic improvement
>>> that suggests to use -> instead of . if the base expression is a
>>> pointer. You find the patch attached.
>>
>> Great idea!  We have some similar-in-concept diagnostics/fixits, but
>> not this one specifically.
>>
>> I see a few issues with this patch, mostly minor.
>>
>> The first is that we like to have reasonably high confidence in our
>> suggestions.  There are plenty of pointer base types where changing
>> '.' into '->' won't actually help;  for example, int*, struct foo**,
>> etc.  We shouldn't recommend using '->' unless the base is
>> specifically a pointer to a record type.
>
> "pointer to a record type for which the field would be valid".  We
> might as well test that the field makes sense as well.


If we don't do the validity check, then we can double-recover from a  
mistyped:

   struct X {
     void setValue(int);
   };

   void f(X *xp) {
     xp.SetValue(17);
   }

:)

	- Doug

From dgregor at apple.com  Fri Dec  4 18:57:25 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Fri, 4 Dec 2009 16:57:25 -0800
Subject: [cfe-dev] Impending initialization rewrite
In-Reply-To: <C05D9B30-6A27-4342-8ECB-B68D249D07DE@apple.com>
References: <C05D9B30-6A27-4342-8ECB-B68D249D07DE@apple.com>
Message-ID: <8D807E1B-CF09-4396-BAD4-66F0C0246AAA@apple.com>


On Nov 30, 2009, at 7:01 AM, Douglas Gregor wrote:

> Over the next few days, I plan to rewrite much of the semantic  
> analysis for initialization to clean up a variety of problems that  
> have surfaced over the past few months.

This turns out to be a huge task. I'm attaching a completely-untested  
version of what I'd like to do, in case anyone wants to discuss the  
approach. Essentially, we're trying to capture everything in an  
InitializationSequence, whose initialization corresponds to  
initialization (har har) that can then be diagnosed (to emit any  
delayed diagnostics) or performed (to produce a complete initializer  
AST). If you've ever looked at ImplicitConversionSequence, it's like  
that... but provides much more information when there is a failure, is  
better encapsulated, and will subsume more of the initialization rules.

My plan is to switch one simple client of reference-initialization  
(AddInitializerToDecl when the VarDecl is a reference) over to this  
initialization logic and write tests to exercise all of the new code  
paths, tweak the diagnostics until I'm happy, etc. Then, I'll move all  
of the CheckReferenceInit callers over to this scheme, and so on.

	- Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: initialization-rewrite-checkpoint-2.patch
Type: application/octet-stream
Size: 80541 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091204/86591b40/attachment-0001.obj 

From clattner at apple.com  Sat Dec  5 01:05:33 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 4 Dec 2009 23:05:33 -0800
Subject: [cfe-dev] Hitting LexIdentifier with a minor performance hit
In-Reply-To: <4B1973BC.7050406@gmail.com>
References: <4B1973BC.7050406@gmail.com>
Message-ID: <5AAE4A37-B67C-4196-AF10-E540F7822FD3@apple.com>


On Dec 4, 2009, at 12:40 PM, Sean Hunt wrote:

> Hey,
> 
> I'd like to split LexIdentifier into two functions so that the actual identifier lexing logic can be reused for user-defined literal suffixes. Since this is a change to the lexing code that will probably have a negative performance impact, however slight (one function call of overhead per identifier is added; one goto is removed per "nasty" identifier (a \, $, or ? is present)), I wanted to check it by first.
> 
> The effective change is that the literal lexing code will be able to use LexIdentifierInternal to parse the suffix when I add that in.

This is one of the most performance sensitive pieces of the entire compiler.  Is there any other way to avoid this (e.g. through code duplication or macros)?  Have you measured the performance impact of this change?

-Chris

From sebastian.redl at getdesigned.at  Sat Dec  5 06:47:24 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Sat, 05 Dec 2009 13:47:24 +0100
Subject: [cfe-dev] RFC: Integrating clang-cc functionality into clang
 (the driver)
In-Reply-To: <6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>
References: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>
	<6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>
Message-ID: <4B1A565C.2090408@getdesigned.at>

Daniel Dunbar wrote:
> Hello again,
>
> This is (the disruptive part of) what is going to happen:
>  1. clang will get the -cc1 mode, which will be equivalent to calling
> clang-cc, and clang will recursively invoke itself (for now). clang
> link will become very slow. :/
>  2. All the tests are going to be rewritten to use 'clang -cc1'
> instead of 'clang-cc'.
>  3. clang-cc will be removed.
>
>   
This would be less disruptive if clang-cc became a symlink to clang, and 
being called as clang-cc would make it assume -cc1.

Sebastian

From nicola.gigante at gmail.com  Sat Dec  5 08:22:43 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sat, 5 Dec 2009 15:22:43 +0100
Subject: [cfe-dev] My first patch to clang
References: <E6E88BF9-577A-4811-B991-EA4698B9EA0F@gmail.com>
Message-ID: <ADED2334-CF3F-4DF8-B170-FB9B97E47FA6@gmail.com>

Il giorno 04/dic/2009, alle ore 22.20, John McCall ha scritto:
> 
> I see a few issues with this patch, mostly minor.
> 
> The first is that we like to have reasonably high confidence in our suggestions.  There are plenty of pointer base types where changing '.' into '->' won't actually help;  for example, int*, struct foo**, etc.  We shouldn't recommend using '->' unless the base is specifically a pointer to a record type.
> 
> The second is that fixits should be aligned with error-recovery whenever possible.  In this case, that means that if we're doing to give a fixit for transforming the '.' into the '->', we should then proceed to do the member lookup, build the expression, etc. as if the user had typed '->'.  It looks like you can make that work very easily:  just (1) pass IsArrow to LookupMemberExpr by reference instead of by value, (2) try to diagnose this error *before* the block in LookupMemberExpr that calls LookupMemberInRecord, and (3) set IsArrow = true when you diagnose.
> 

Ok, I've tried to do what you suggested. The new patch is attached. 
Now it seems to generate the new diagnostic only with record types, as expected.

However, I'm not very sure about the error recovery.
Generally speaking, how does it work in clang? In the case of recoverable errors, the lexer/parser/sema code continues as the user had typed the right code?

Thanks,
Nicola

-------------- next part --------------
A non-text attachment was scrubbed...
Name: member_pointer_suggestion.patch
Type: application/octet-stream
Size: 3398 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091205/396ce2ce/attachment.obj 
-------------- next part --------------


From sorokin at rain.ifmo.ru  Sat Dec  5 11:52:57 2009
From: sorokin at rain.ifmo.ru (Ivan Sorokin)
Date: Sat, 05 Dec 2009 20:52:57 +0300
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <3E01FDFF-594F-478D-8350-6EFC436826EA@apple.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
	<3E01FDFF-594F-478D-8350-6EFC436826EA@apple.com>
Message-ID: <4B1A9DF9.5080706@rain.ifmo.ru>

Chris Lattner wrote:
> "pointer to a record type for which the field would be valid".  We  
> might as well test that the field makes sense as well.
>
> Thanks again for working on this, it's great to get this enhancement,
>
>   
You need also to check if class has overloaded operator->.

Look at this example:

struct a
{
  int b;
};

struct c
{
  a * operator->();

  int d;
};

int main()
{
  c * c;
  c.d;    // do not try to suggest replacement for c->d (!)
  return 0;
}



From sebastian.redl at getdesigned.at  Sat Dec  5 11:57:59 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Sat, 05 Dec 2009 18:57:59 +0100
Subject: [cfe-dev] Impending initialization rewrite
In-Reply-To: <8D807E1B-CF09-4396-BAD4-66F0C0246AAA@apple.com>
References: <C05D9B30-6A27-4342-8ECB-B68D249D07DE@apple.com>
	<8D807E1B-CF09-4396-BAD4-66F0C0246AAA@apple.com>
Message-ID: <4B1A9F27.4060809@getdesigned.at>

Douglas Gregor wrote:
> Essentially, we're trying to capture everything in an 
> InitializationSequence, whose initialization corresponds to 
> initialization (har har) that can then be diagnosed (to emit any 
> delayed diagnostics) or performed (to produce a complete initializer 
> AST). If you've ever looked at ImplicitConversionSequence, it's like 
> that... but provides much more information when there is a failure, is 
> better encapsulated, and will subsume more of the initialization rules.
It looks very nice. I like the approach.
What about zero-initialization? Does it still exist in C++0x?
>
> My plan is to switch one simple client of reference-initialization 
> (AddInitializerToDecl when the VarDecl is a reference) over to this 
> initialization logic and write tests to exercise all of the new code 
> paths, tweak the diagnostics until I'm happy, etc. Then, I'll move all 
> of the CheckReferenceInit callers over to this scheme, and so on.
I suppose that makes sense. Alternatively you could try to move 
AddInitializerToDecl over completely, step by step, and then follow with 
the other places that do initialization. But I think your approach is 
better.

Sebastian

From cdavis at mymail.mines.edu  Sat Dec  5 12:18:50 2009
From: cdavis at mymail.mines.edu (Charles Davis)
Date: Sat, 05 Dec 2009 11:18:50 -0700
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <4B1A9DF9.5080706@rain.ifmo.ru>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>	<3E01FDFF-594F-478D-8350-6EFC436826EA@apple.com>
	<4B1A9DF9.5080706@rain.ifmo.ru>
Message-ID: <4B1AA40A.5050302@mymail.mines.edu>

Ivan Sorokin wrote:
> Chris Lattner wrote:
>> "pointer to a record type for which the field would be valid".  We  
>> might as well test that the field makes sense as well.
>>
>> Thanks again for working on this, it's great to get this enhancement,
>>
>>   
> You need also to check if class has overloaded operator->.
No he doesn't. That's because, if you have a pointer to an object that
has an overloaded operator->(), using the -> operator on the pointer
doesn't cause the operator->() function to get called. I think it's best
shown with an example; continuing your example:

int main(void)
{
    c * c;

    c.d;    // illegal, suggest replacement
    c->d;   // dereferences c, accesses c::d
    (*c)->d;// dereferences c, calls c::operator->(), tries to
            // dereference a pointer to an object of type a and access
            // a::d (which fails)
    (*c)->b;// dereferences c, calls c::operator->(), dereferences a
            // pointer to an object of type a and accesses a::b

    return 0;
}

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


From clattner at apple.com  Sat Dec  5 12:33:43 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 5 Dec 2009 10:33:43 -0800
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <4B1AA40A.5050302@mymail.mines.edu>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
	<3E01FDFF-594F-478D-8350-6EFC436826EA@apple.com>
	<4B1A9DF9.5080706@rain.ifmo.ru> <4B1AA40A.5050302@mymail.mines.edu>
Message-ID: <51085F97-4806-4E4C-8CBA-B5DA0D42A163@apple.com>


On Dec 5, 2009, at 10:18 AM, Charles Davis wrote:

> Ivan Sorokin wrote:
>> Chris Lattner wrote:
>>> "pointer to a record type for which the field would be valid".  We  
>>> might as well test that the field makes sense as well.
>>> 
>>> Thanks again for working on this, it's great to get this enhancement,
>>> 
>>> 
>> You need also to check if class has overloaded operator->.
> No he doesn't.

Even if he does, his patch is still a very nice improvement over what we have.  Handling operator-> can be a follow-on :)

-Chris

From sorokin at rain.ifmo.ru  Sat Dec  5 12:37:52 2009
From: sorokin at rain.ifmo.ru (Ivan Sorokin)
Date: Sat, 05 Dec 2009 21:37:52 +0300
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <4B1AA40A.5050302@mymail.mines.edu>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>	<3E01FDFF-594F-478D-8350-6EFC436826EA@apple.com>
	<4B1A9DF9.5080706@rain.ifmo.ru> <4B1AA40A.5050302@mymail.mines.edu>
Message-ID: <4B1AA880.8050002@rain.ifmo.ru>

Charles Davis wrote:
> No he doesn't. That's because, if you have a pointer to an object that
> has an overloaded operator->(), using the -> operator on the pointer
> doesn't cause the operator->() function to get called. I think it's best
> shown with an example;
Yes. You are right.

From cdavis at mymail.mines.edu  Sat Dec  5 16:15:31 2009
From: cdavis at mymail.mines.edu (Charles Davis)
Date: Sat, 05 Dec 2009 15:15:31 -0700
Subject: [cfe-dev] __builtin_sin() and friends not compiling?
Message-ID: <4B1ADB83.6000702@mymail.mines.edu>

Hi,

I noticed this comment in lib/CodeGen/CGBuiltin.cpp:

  // If this is an alias for a libm function (e.g. __builtin_sin) turn
it into
  // that function.
  if (getContext().BuiltinInfo.isLibFunction(BuiltinID) ||
      getContext().BuiltinInfo.isPredefinedLibFunction(BuiltinID))
    return EmitCall(CGM.getBuiltinLibFunction(FD, BuiltinID),
                    E->getCallee()->getType(), E->arg_begin(),
                    E->arg_end());

But this is what I find in include/clang/Basic/Builtins.def:

// Standard unary libc/libm functions with double/float/long double
variants:
BUILTIN(__builtin_acos , "dd"  , "nc")
...
BUILTIN(__builtin_tanl, "LdLd", "nc")

So none of these builtins that should be marked as LibFunctions or
PredefinedLibFunctions are marked as such. Is there a good reason for
this? Because when I try to use one of them, I get an error:

$ cat t.c
int main(void)
{
	__builtin_sin(0.0);
	return 0;
}

$ clang t.c
t.c:3:2: error: cannot compile this builtin function yet
        __builtin_sin(0.0);
        ^~~~~~~~~~~~~~~~~~
1 diagnostic generated.

Should I file a PR?

Chip

From nicola.gigante at gmail.com  Sun Dec  6 06:55:19 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sun, 6 Dec 2009 13:55:19 +0100
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <654693A2-758D-4470-94F2-F65E81EB125C@apple.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
	<E6E88BF9-577A-4811-B991-EA4698B9EA0F@gmail.com>
	<654693A2-758D-4470-94F2-F65E81EB125C@apple.com>
Message-ID: <5954B0FD-AF85-473D-9D4A-5734D50F5625@gmail.com>


Il giorno 05/dic/2009, alle ore 20.23, John McCall ha scritto:
> 
> That isn't quite what I meant.  You've inserted it like this:
> 
>   if (const RecordType *RTy = BaseType->getAs<RecordType>()) {
> +		
> +		if(!IsArrow && BaseType->isPointerType()) {
> 
> This can never be satisfied, because it's inside an 'if' statement that checks whether the type is a record type.  A type can't be both a record type and a pointer type!
> 
Yes, that's a stupid mistake..

> 
> Exactly.  You should change the input to look exactly like it would look if the user had typed '->' instead.  That's why you want your check to run before LookupMemberExpr tries to adjust the base type to the pointee type and so on.
> 

I think I've understood what you mean. I've attached Yet Another Patch :) In the meantime, I noticed that the case of a '.' used for a pointer was similar, so I generalized the suggestion. Now I think it works, because this source code:

#include <stdio.h>

struct type
{
  int member;
};

int main()
{
        struct type *p_struct;
        int *p_int;
        int a_int;
        struct type a_struct;

        p_struct.member = 7;
        p_int.member = 7;
        a_struct->member = 7;
        a_int->member = 7;

        return 0;
}

Produces this output:

prova.c:15:10: error: member reference type 'struct type *' is a pointer; maybe you meant to use '->'?
        p_struct.member = 7;
        ~~~~~~~~^
                ->
prova.c:16:8: error: member reference base type 'int *' is not a structure or union
        p_int.member = 7;
        ~~~~~ ^
prova.c:17:10: error: member reference type 'struct type' is not a pointer; maybe you meant to use '.'?
        a_struct->member = 7;
        ~~~~~~~~^~
                .
prova.c:18:9: error: member reference type 'int' is not a pointer
        a_int->member = 7;
        ~~~~~  ^
4 diagnostics generated.


I think it's the right output. The only thing I can't understand is: All the four errors use BaseExpr->getSourceRange() to get the range of the base expressions, but in the first and the third errors (the two added by my patch), the range is wrong because also includes the arrow (or the dot). Is it my fault?

Bye bye,

Nicola

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

From nicola.gigante at gmail.com  Sun Dec  6 12:09:53 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sun, 6 Dec 2009 19:09:53 +0100
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <4B1BEADA.7060104@gmail.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
	<E6E88BF9-577A-4811-B991-EA4698B9EA0F@gmail.com>
	<654693A2-758D-4470-94F2-F65E81EB125C@apple.com>
	<5954B0FD-AF85-473D-9D4A-5734D50F5625@gmail.com>
	<4B1BEADA.7060104@gmail.com>
Message-ID: <17E4E70E-D082-4EDF-BDAB-B9C26B837016@gmail.com>

	
Il giorno 06/dic/2009, alle ore 18.33, Sean Hunt ha scritto:

> Nicola Gigante wrote:
> 
> The caret is aligned with the SourceLocation passed as an argument to Diag; the range is based on the SourceRange you pass in later.

Exactly! What I meant is that in these four diagnostics, the source range is always obtained with BaseExpr->getSourceRange() (and BaseExpr doesn't change in the meantime). However, in two of the four cases, the range highlighted in the output also includes the '->' or '.'. I think this isn't correct and I can't understand why this happens. Is it my fault?

Anyway, how about the patch in general? Is it ok? 

Thanks,

Nicola

From dgregor at apple.com  Sun Dec  6 13:11:06 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Sun, 6 Dec 2009 11:11:06 -0800
Subject: [cfe-dev] Impending initialization rewrite
In-Reply-To: <4B1A9F27.4060809@getdesigned.at>
References: <C05D9B30-6A27-4342-8ECB-B68D249D07DE@apple.com>
	<8D807E1B-CF09-4396-BAD4-66F0C0246AAA@apple.com>
	<4B1A9F27.4060809@getdesigned.at>
Message-ID: <0A5D9F37-4A67-444F-84EC-193A6360E9D5@apple.com>


On Dec 5, 2009, at 9:57 AM, Sebastian Redl wrote:

> Douglas Gregor wrote:
>> Essentially, we're trying to capture everything in an InitializationSequence, whose initialization corresponds to initialization (har har) that can then be diagnosed (to emit any delayed diagnostics) or performed (to produce a complete initializer AST). If you've ever looked at ImplicitConversionSequence, it's like that... but provides much more information when there is a failure, is better encapsulated, and will subsume more of the initialization rules.
> It looks very nice. I like the approach.
> What about zero-initialization? Does it still exist in C++0x?

It happens as part of value initialization for non-class and POD types; I don't think it's ever directly "invoked" by anywhere else in the language.

>> My plan is to switch one simple client of reference-initialization (AddInitializerToDecl when the VarDecl is a reference) over to this initialization logic and write tests to exercise all of the new code paths, tweak the diagnostics until I'm happy, etc. Then, I'll move all of the CheckReferenceInit callers over to this scheme, and so on.
> I suppose that makes sense. Alternatively you could try to move AddInitializerToDecl over completely, step by step, and then follow with the other places that do initialization. But I think your approach is better.


I want to try to get nicer diagnostics than "candidate function here" for overload-resolution failures. I *think* I have the right interface for that, but I want to try it first with a very narrow application area (reference initialization) before I commit to this interface.

	- Doug

From rjmccall at apple.com  Sun Dec  6 17:40:22 2009
From: rjmccall at apple.com (John McCall)
Date: Sun, 6 Dec 2009 15:40:22 -0800
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <5954B0FD-AF85-473D-9D4A-5734D50F5625@gmail.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
	<E6E88BF9-577A-4811-B991-EA4698B9EA0F@gmail.com>
	<654693A2-758D-4470-94F2-F65E81EB125C@apple.com>
	<5954B0FD-AF85-473D-9D4A-5734D50F5625@gmail.com>
Message-ID: <4994F773-97F6-4ABE-BD0F-CF0161B49C79@apple.com>

On Dec 6, 2009, at 4:55 AM, Nicola Gigante wrote:
> Il giorno 05/dic/2009, alle ore 20.23, John McCall ha scritto:
>> 
>> Exactly.  You should change the input to look exactly like it would look if the user had typed '->' instead.  That's why you want your check to run before LookupMemberExpr tries to adjust the base type to the pointee type and so on.
> 4 diagnostics generated.

This seems like good output.

> I think it's the right output. The only thing I can't understand is: All the four errors use BaseExpr->getSourceRange() to get the range of the base expressions, but in the first and the third errors (the two added by my patch), the range is wrong because also includes the arrow (or the dot). Is it my fault?

The replacement fixit causes the original text to be underlined.  Don't worry about it.

> <member_pointer_suggestion.patch>

The functionality looks good!  Please use tabs instead of spaces, and don't put spaces inside 'if' conditions like this:

+		else if ( BaseType->isRecordType() ) {

Do you need someone to commit this for you?

John.

From clattner at apple.com  Sun Dec  6 20:09:27 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 6 Dec 2009 18:09:27 -0800
Subject: [cfe-dev] __builtin_sin() and friends not compiling?
In-Reply-To: <4B1ADB83.6000702@mymail.mines.edu>
References: <4B1ADB83.6000702@mymail.mines.edu>
Message-ID: <514A66F2-B47E-4FBB-8170-E39C9F6D3FD3@apple.com>


On Dec 5, 2009, at 2:15 PM, Charles Davis wrote:

> Hi,
> 
> I noticed this comment in lib/CodeGen/CGBuiltin.cpp:

Looks like a simple oversight, I fixed this in r90736, thanks!

-Chris


From victor.zverovich at googlemail.com  Mon Dec  7 01:00:29 2009
From: victor.zverovich at googlemail.com (Victor Zverovich)
Date: Mon, 7 Dec 2009 07:00:29 +0000
Subject: [cfe-dev] Info diagnostic level
In-Reply-To: <6a8523d60911212151t56d9fc43s36d1e23bc7b18856@mail.gmail.com>
References: <a88d534c0911200111j394623b1o578fd2b916554294@mail.gmail.com>
	<6a8523d60911212151t56d9fc43s36d1e23bc7b18856@mail.gmail.com>
Message-ID: <a88d534c0912062300q4e04ca8cn4af0992870a74b7d@mail.gmail.com>

Hi Daniel,

Sorry, I've been busy with my main project and didn't follow the list for
some time.

The progress information example was probably not a good one since it is
indeed structured and better handled differently. However, I want to use
diagnostics to return unstructured information. My use case is the same as
you described. I want to output various information from the driver program
of my translator and was thinking of using Diagnostics instead of writing to
stderr for this.

Best regards,
Victor

2009/11/22 Daniel Dunbar <daniel at zuster.org>

> Hi Victor,
>
> Can you explain a bit more about what you want to do with this?
>
> If you want to return structured information (e.g., progress
> information), I'm not sure adding another diagnostic level is the
> right approach, since it is too generic and clients won't necessarily
> know how to deal with it (from an API level). If it is unstructured,
> then we need to clarify what the level means w.r.t. the existing
> levels.
>
> The reason I ask is that the driver has some similar issues where it
> currently dumps information to stderr (-v, -print-search-dirs, etc).
> In theory, I'd like to not have this buried in the Driver library but
> let the client have control over it, but I haven't decided how I want
> to do this (the obvious approaches are to extend Diagnostics, or use
> special diagnostic classes for it, or alternately use a different
> callback mechanism).
>
>  - Daniel
>
> On Fri, Nov 20, 2009 at 1:11 AM, Victor Zverovich
> <victor.zverovich at googlemail.com> wrote:
> > I am actively using the clang's Basic library in my project and in
> > particular its diagnostic part which is great.
> > However it has the following limitation: it is not possible to report an
> > "informational" message which is neither warning nor error through it.
> While
> > clang doesn't need this functionality it may be useful for other users
> (me
> > being one of them :)) without any overhead for clang. The attached patch
> > introduces the Info diagnostic level.
> > Thanks,
> > Victor
> >
> > _______________________________________________
> > 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/20091207/0711ed95/attachment.html 

From sebastian.redl at getdesigned.at  Mon Dec  7 02:27:28 2009
From: sebastian.redl at getdesigned.at (Sebastian Redl)
Date: Mon, 07 Dec 2009 09:27:28 +0100
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <4994F773-97F6-4ABE-BD0F-CF0161B49C79@apple.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
	<E6E88BF9-577A-4811-B991-EA4698B9EA0F@gmail.com>
	<654693A2-758D-4470-94F2-F65E81EB125C@apple.com>
	<5954B0FD-AF85-473D-9D4A-5734D50F5625@gmail.com>
	<4994F773-97F6-4ABE-BD0F-CF0161B49C79@apple.com>
Message-ID: <a9a4cf256b139eca1550d28fb5291756@localhost>


On Sun, 6 Dec 2009 15:40:22 -0800, John McCall <rjmccall at apple.com> wrote:
> The functionality looks good!  Please use tabs instead of spaces,

Er, I think you swapped this. Clang uses spaces only.

Sebastian


From cedric.venet at laposte.net  Mon Dec  7 02:31:32 2009
From: cedric.venet at laposte.net (=?ISO-8859-1?Q?C=E9dric_Venet?=)
Date: Mon, 07 Dec 2009 09:31:32 +0100
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <4994F773-97F6-4ABE-BD0F-CF0161B49C79@apple.com>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>	<E6E88BF9-577A-4811-B991-EA4698B9EA0F@gmail.com>	<654693A2-758D-4470-94F2-F65E81EB125C@apple.com>	<5954B0FD-AF85-473D-9D4A-5734D50F5625@gmail.com>
	<4994F773-97F6-4ABE-BD0F-CF0161B49C79@apple.com>
Message-ID: <4B1CBD64.3010600@laposte.net>

Le 07/12/2009 00:40, John McCall a ?crit :
>> <member_pointer_suggestion.patch>
>>      
> The functionality looks good!  Please use tabs instead of spaces, and don't put spaces inside 'if' conditions like this:
>    

you probably means use spaces instead of tabs, isn't it?



From rjmccall at apple.com  Mon Dec  7 02:53:20 2009
From: rjmccall at apple.com (John McCall)
Date: Mon, 7 Dec 2009 00:53:20 -0800
Subject: [cfe-dev] My first patch to clang
In-Reply-To: <a9a4cf256b139eca1550d28fb5291756@localhost>
References: <D06E7F30-2978-440A-A7F2-0053DC4CB53D@gmail.com>
	<B62EC853-ED63-4E91-8DAB-D61204F43F52@apple.com>
	<E6E88BF9-577A-4811-B991-EA4698B9EA0F@gmail.com>
	<654693A2-758D-4470-94F2-F65E81EB125C@apple.com>
	<5954B0FD-AF85-473D-9D4A-5734D50F5625@gmail.com>
	<4994F773-97F6-4ABE-BD0F-CF0161B49C79@apple.com>
	<a9a4cf256b139eca1550d28fb5291756@localhost>
Message-ID: <01639893-5D0D-4F8D-899A-7F20B8C2ED33@apple.com>


On Dec 7, 2009, at 12:27 AM, Sebastian Redl wrote:

> 
> On Sun, 6 Dec 2009 15:40:22 -0800, John McCall <rjmccall at apple.com> wrote:
>> The functionality looks good!  Please use tabs instead of spaces,
> 
> Er, I think you swapped this. Clang uses spaces only.

Yes, I mistyped this, thank you.  No tabs, please.

John.

From daniel at zuster.org  Mon Dec  7 11:30:05 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Mon, 7 Dec 2009 09:30:05 -0800
Subject: [cfe-dev] RFC: Integrating clang-cc functionality into clang
	(the driver)
In-Reply-To: <4B1A565C.2090408@getdesigned.at>
References: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>
	<6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>
	<4B1A565C.2090408@getdesigned.at>
Message-ID: <6a8523d60912070930qbf55ca8ke4e8501e870e8e8f@mail.gmail.com>

On Sat, Dec 5, 2009 at 4:47 AM, Sebastian Redl
<sebastian.redl at getdesigned.at> wrote:
> Daniel Dunbar wrote:
>>
>> Hello again,
>>
>> This is (the disruptive part of) what is going to happen:
>> ?1. clang will get the -cc1 mode, which will be equivalent to calling
>> clang-cc, and clang will recursively invoke itself (for now). clang
>> link will become very slow. :/
>> ?2. All the tests are going to be rewritten to use 'clang -cc1'
>> instead of 'clang-cc'.
>> ?3. clang-cc will be removed.
>>
>>
>
> This would be less disruptive if clang-cc became a symlink to clang, and
> being called as clang-cc would make it assume -cc1.

That is true, but I don't see why we would want to maintain clang-cc,
its just extra gunk in the build system and extra complexity for the
user. I'll do it if out-voted though.

 - Daniel


From dgregor at apple.com  Mon Dec  7 12:47:14 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 7 Dec 2009 10:47:14 -0800
Subject: [cfe-dev] RFC: Integrating clang-cc functionality into
	clang	(the driver)
In-Reply-To: <6a8523d60912070930qbf55ca8ke4e8501e870e8e8f@mail.gmail.com>
References: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>
	<6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>
	<4B1A565C.2090408@getdesigned.at>
	<6a8523d60912070930qbf55ca8ke4e8501e870e8e8f@mail.gmail.com>
Message-ID: <1B452059-33CF-402D-9ED7-5BE2D9B66717@apple.com>


On Dec 7, 2009, at 9:30 AM, Daniel Dunbar wrote:

> On Sat, Dec 5, 2009 at 4:47 AM, Sebastian Redl
> <sebastian.redl at getdesigned.at> wrote:
>> Daniel Dunbar wrote:
>>> 
>>> Hello again,
>>> 
>>> This is (the disruptive part of) what is going to happen:
>>>  1. clang will get the -cc1 mode, which will be equivalent to calling
>>> clang-cc, and clang will recursively invoke itself (for now). clang
>>> link will become very slow. :/
>>>  2. All the tests are going to be rewritten to use 'clang -cc1'
>>> instead of 'clang-cc'.
>>>  3. clang-cc will be removed.
>>> 
>>> 
>> 
>> This would be less disruptive if clang-cc became a symlink to clang, and
>> being called as clang-cc would make it assume -cc1.
> 
> That is true, but I don't see why we would want to maintain clang-cc,
> its just extra gunk in the build system and extra complexity for the
> user. I'll do it if out-voted though.

I'd rather just kill clang-cc outright. It's much cleaner from the user's perspective to have a single "clang" that does everything. 

Of course, those of us who *work* on Clang will have to retrain our fingers not to use clang-cc :)

	- Doug

From mrs at apple.com  Mon Dec  7 13:26:29 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 7 Dec 2009 11:26:29 -0800
Subject: [cfe-dev] RFC: Integrating clang-cc functionality
	into	clang	(the driver)
In-Reply-To: <1B452059-33CF-402D-9ED7-5BE2D9B66717@apple.com>
References: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>
	<6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>
	<4B1A565C.2090408@getdesigned.at>
	<6a8523d60912070930qbf55ca8ke4e8501e870e8e8f@mail.gmail.com>
	<1B452059-33CF-402D-9ED7-5BE2D9B66717@apple.com>
Message-ID: <CE58B8F2-4E82-49D9-A462-7DCB5BA69945@apple.com>

On Dec 7, 2009, at 10:47 AM, Douglas Gregor wrote:
> I'd rather just kill clang-cc outright.

Me too.

> Of course, those of us who *work* on Clang will have to retrain our fingers not to use clang-cc :)

My fingers are looking forward to that day.

From edwintorok at gmail.com  Mon Dec  7 13:51:24 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Mon, 07 Dec 2009 21:51:24 +0200
Subject: [cfe-dev] RFC: Integrating clang-cc functionality into clang
 (the driver)
In-Reply-To: <6a8523d60912040935ncf3b5c4ic4fcbcbdbf6fe6ac@mail.gmail.com>
References: <6a8523d60911031307vfd5b4d1mdc3555cb081789d@mail.gmail.com>	
	<6a8523d60912040820j18b82ab7r93faffd36c725124@mail.gmail.com>	
	<4B193DE1.7000306@gmail.com>
	<6a8523d60912040935ncf3b5c4ic4fcbcbdbf6fe6ac@mail.gmail.com>
Message-ID: <4B1D5CBC.4020301@gmail.com>

On 2009-12-04 19:35, Daniel Dunbar wrote:
> 2009/12/4 T?r?k Edwin <edwintorok at gmail.com>:
>   
>> On 2009-12-04 18:20, Daniel Dunbar wrote:
>>     
>>> Hello again,
>>>
>>> All the major pieces of the clang / clang-cc integration project are
>>> now in place, which means its time to put them to work! :)
>>>
>>>       
>> Hi,
>>
>> So can I now invoke the driver directly (after forking, in case it
>> crashes),
>> without the need for execve(), and have the ability to turn all the
>> clang-cc commandline flags on/off?
>>     
>
> Yes. Look at ASTUnit::LoadFromSource for example.
>
>   
>> Is there a way now to get diagnostics directly, without the need to
>> redirect/parse the output?
>>     
>
> Yes.
>   

Ok.

>   
>> Also will cl::ParseCommandLineOptions still work for LLVM commandline
>> options?
>>     
>
> It works, but it isn't called by default. We could add an -mllvm for
> clang-cc for this, although I'd rather not.
>   

Thats fine, I can call that in my code before calling the driver class.

>   
>> I am currently using some rather low-level switches for clang-cc, so I
>> might as well ask now whether these are going away in the future or not:
>> -ffreestanding -nostdinc -disable-free -fdiagnostics-show-option
>> -fmessage-length=80
>> -fcolor-diagnostics -triple clambc-generic-generic -include bytecode.h
>> -Wall -warn-dead-stores  -warn-security-syntactic -analyzer-eagerly-assume
>> -v -g -E -S
>>     
>
> No, although it would be better for you to use the driver to construct
> a CompilerInvocation, and then tweak the resulting object. That way
> you are insulated from changes to the clang/clang
> -cc1/CompilerInvocation API.
>   

Yes, that makes sense.

>   
>> Also I've been experimenting at some point with writing a simple editor
>> that uses clang for syntax highlighting/completion.
>> There were 2 issues:
>>  - creating the Preprocessor object involved setting lot of language
>> related stuff, like implicitint, accesscontrol, bool support, and so on.
>> Is there a way to just tell it to create with the language defaults that
>> the clang driver would use? (and eventually tell it about
>> -std=c99, and it automatically sets up whatever clang sets up for c99).
>>     
>
> You can do this easily now via CompilerInvocation and
> CompilerInstance. You can look at how the FrontendAction wrapper
> implements this, for example.
>
>   
>> - This isn't necesarely related to your driver work, but I didn't see
>> any support for reusing previous parse results, like reparsing only the
>> portion of the
>> file/membuffer that changed. Can that somehow be accomplished with the
>> new driver infrastructure? (i.e. tell it that you've previously compiled
>> this file
>> with same driver, and now you only want to reparse/rebuild the AST for
>> the changed part).
>>     
>
> This doesn't really have anything to do with the driver, and we don't
> have the underlying feature support for this.
>
> It's great to hear someone is working on this kind of stuff, please
> consider packing your work up as an example we can include with clang!
>   

Ok, I'll do that when I have some free time to update it to the new
clang API.
What license is acceptable for the examples, GPL2 good enough?

Best regards,
--Edwin

From john.thompson.jtsoftware at gmail.com  Mon Dec  7 14:55:35 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Mon, 7 Dec 2009 12:55:35 -0800
Subject: [cfe-dev] Implementing Altivec vector support questions
Message-ID: <aad8390912071255u6edde8c1v3ef6cda0b2e93ad@mail.gmail.com>

1. In implementing vector and __vector, which is better?:

A.  Don't make it a keyword, but if LangOptions::AltiVec is set and a
kw_identifier with the name "vector" or "__vector" is followed by a numeric
type keyword, make the type a vector type.

B. Make vector and __vector a keyword if LangOptions::AltiVec is set, and if
not followed by a numeric type keyword, treat it as an identifier.
My guess is that A is better as it involves less fixing up of cases where an
identifier with the name of "vector" can occur.

2. Regarding the typing, I'm thinking internally it would be treated just as
if __attribute__((vector_size(16)) were applied to the type, right?

3. With __attribute__((vector_size(16)), does the Clang code generation
already output everything LLVM needs to support the Altivec vectors?

For example, in looking at the code generated for some code using an
"__attribute__((vector_size(16)) float" variable or return type, the .ll
file uses "<4 x float>".  On a PowerPC platform supporting Altivec,
does LLVM automatically know to map that to a vector register?

4.  I'm guessing the Altivec functions can be implemented as Clang built-in
functions that map to calls to LLVM's altivec intrinsic functions, right?  I
haven't researched this much yet.

5.  Any suggestions or other things I ought to know at this early point?

Thanks.

-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/20091207/aa639146/attachment.html 

From xuzhongxing at gmail.com  Mon Dec  7 20:55:13 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Tue, 8 Dec 2009 10:55:13 +0800
Subject: [cfe-dev]  BlockImplementation.txt
Message-ID: <5400aeb80912071855i9700ab8t35c7613dcb3477f8@mail.gmail.com>

In BlockImplementation.txt, line 94,

static struct __block_descriptor_1 {
    unsigned long int reserved;
    unsigned long int Block_size;
} __block_descriptor_1 = { 0, sizeof(struct __block_literal_1),
__block_invoke_1 };

Why there is three initializers while the struct only has two members?

From fjahanian at apple.com  Mon Dec  7 21:52:42 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Mon, 7 Dec 2009 19:52:42 -0800
Subject: [cfe-dev] BlockImplementation.txt
In-Reply-To: <5400aeb80912071855i9700ab8t35c7613dcb3477f8@mail.gmail.com>
References: <5400aeb80912071855i9700ab8t35c7613dcb3477f8@mail.gmail.com>
Message-ID: <1FA875EE-BA97-457F-9DB4-A7B736D0121C@apple.com>

Complete description should be:

struct __block_descriptor {
  unsigned long int reserved;     // NULL
  unsigned long int Block_size;  // sizeof(struct Block_literal_1)

  // optional helper functions
  void *CopyFuncPtr; // When BLOCK_HAS_COPY_DISPOSE is set  
(withCopyDispose true)
  void *DestroyFuncPtr; // When BLOCK_HAS_COPY_DISPOSE is set  
(withCopyDispose true)
}

- Fariborz

On Dec 7, 2009, at 6:55 PM, Zhongxing Xu wrote:

> In BlockImplementation.txt, line 94,
>
> static struct __block_descriptor_1 {
>    unsigned long int reserved;
>    unsigned long int Block_size;
> } __block_descriptor_1 = { 0, sizeof(struct __block_literal_1),
> __block_invoke_1 };
>
> Why there is three initializers while the struct only has two members?
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From clattner at apple.com  Tue Dec  8 12:47:20 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 8 Dec 2009 10:47:20 -0800
Subject: [cfe-dev] Implementing Altivec vector support questions
In-Reply-To: <aad8390912071255u6edde8c1v3ef6cda0b2e93ad@mail.gmail.com>
References: <aad8390912071255u6edde8c1v3ef6cda0b2e93ad@mail.gmail.com>
Message-ID: <6E5AF218-DC8A-45D8-9DA7-B527CE549164@apple.com>

On Dec 7, 2009, at 12:55 PM, John Thompson wrote:
> 1. In implementing vector and __vector, which is better?:

I'm not familiar with the intricacies of this extension, so I don't  
know the technical feasibility of the different approaches, but here's  
MHO:

>
> A.  Don't make it a keyword, but if LangOptions::AltiVec is set and  
> a kw_identifier with the name "vector" or "__vector" is followed by  
> a numeric type keyword, make the type a vector type.

This would be the "context sensitive keyword" approach I guess.  I  
tend to not like this because it can be fragile / unpredictable.

>  B. Make vector and __vector a keyword if LangOptions::AltiVec is  
> set, and if not followed by a numeric type keyword, treat it as an  
> identifier.
> My guess is that A is better as it involves less fixing up of cases  
> where an identifier with the name of "vector" can occur.

I don't know how much magic is inherent in this language extension.   
Would it be bad to to make __vector *always* be on when AltiVec is  
enabled (whether or not it is followed by a 'numeric type keyword')?   
We could then make 'vector' be fuzzier.  I'm still vaguely  
uncomfortable with 'vector' changing semantics depending on its  
lexical context, but understand that you probably don't have a choice  
here :)

>
> 2. Regarding the typing, I'm thinking internally it would be treated  
> just as if __attribute__((vector_size(16)) were applied to the type,  
> right?

Sure, if that works!  I don't know what __vector does.

> 3. With __attribute__((vector_size(16)), does the Clang code  
> generation already output everything LLVM needs to support the  
> Altivec vectors?

I think so, though we also need an 'altivec.h' for clang to use, in a  
similar spirit to 'xmmintrin.h' for sse.

> For example, in looking at the code generated for some code using an  
> "__attribute__((vector_size(16)) float" variable or return type,  
> the .ll file uses "<4 x float>".  On a PowerPC platform supporting  
> Altivec, does LLVM automatically know to map that to a vector  
> register?

Yes.  However, noone has done any ABI compatibility testing on  
PowerPC, even for simple types.  It is likely that there are a bunch  
of bugs passing structures by value etc.  Daniel has a nice randomized  
testcase generator for finding cases that need to be improved.
>
> 4.  I'm guessing the Altivec functions can be implemented as Clang  
> built-in functions that map to calls to LLVM's altivec intrinsic  
> functions, right?  I haven't researched this much yet.

Yes, we support the 'unusual' altivec builtins in llvm-gcc  by mapping  
them onto the LLVM intrinsics in llvm/include/llvm/ 
IntrinsicsPowerPC.td.  The simple ones make directly onto llvm IR  
vector instructions.

-Chris


From john.thompson.jtsoftware at gmail.com  Tue Dec  8 13:30:58 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 8 Dec 2009 11:30:58 -0800
Subject: [cfe-dev] Implementing Altivec vector support questions
In-Reply-To: <6E5AF218-DC8A-45D8-9DA7-B527CE549164@apple.com>
References: <aad8390912071255u6edde8c1v3ef6cda0b2e93ad@mail.gmail.com>
	<6E5AF218-DC8A-45D8-9DA7-B527CE549164@apple.com>
Message-ID: <aad8390912081130t70275042yca27f59117ac6099@mail.gmail.com>

 Thanks, Chris.


> I don't know how much magic is inherent in this language extension.  Would
> it be bad to to make __vector *always* be on when AltiVec is enabled
> (whether or not it is followed by a 'numeric type keyword')?  We could then
> make 'vector' be fuzzier.  I'm still vaguely uncomfortable with 'vector'
> changing semantics depending on its lexical context, but understand that you
> probably don't have a choice here :)
>

I think I see.  Treat "__vector" as a normal keyword token, and if "vector"
is encountered, I still do the context check and effectively treat it as
"__vector"?


> Sure, if that works!  I don't know what __vector does.
>

My understanding is that "__vector" (or "vector") in this context is always
followed by a numeric type, i.e. "_vector unsigned int".  My guess was that
this would be effecticvely equivalent to "__attribute__((vector_size(16)))
unsigned int", so the plan would then be to have the resulting type for
these two be the same after the semantic action.

> I think so, though we also need an 'altivec.h' for clang to use, in a
> similar spirit to 'xmmintrin.h' for sse.
>

Yes, probably, if nothing else just to be compatible with gcc.  (It's
mentioned in the Altivec standard in section 2.6 of
http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf).  I was
told it was orginally deprecated, but then left in to help with early
implementation.  Looking at the one we have for the PS3 gcc compiler, it
seems to be the PowerPC version, and mostly just maps Altivec names to the
"__builtin_*" functions.


> Yes.  However, noone has done any ABI compatibility testing on PowerPC,
> even for simple types.  It is likely that there are a bunch of bugs passing
> structures by value etc.  Daniel has a nice randomized testcase generator
> for finding cases that need to be improved.
>

I guess we'll have to cross that bridge when we get to it.

-John


On Tue, Dec 8, 2009 at 10:47 AM, Chris Lattner <clattner at apple.com> wrote:

> On Dec 7, 2009, at 12:55 PM, John Thompson wrote:
>
>> 1. In implementing vector and __vector, which is better?:
>>
>
> I'm not familiar with the intricacies of this extension, so I don't know
> the technical feasibility of the different approaches, but here's MHO:
>
>
>
>> A.  Don't make it a keyword, but if LangOptions::AltiVec is set and a
>> kw_identifier with the name "vector" or "__vector" is followed by a numeric
>> type keyword, make the type a vector type.
>>
>
> This would be the "context sensitive keyword" approach I guess.  I tend to
> not like this because it can be fragile / unpredictable.
>
>
>  B. Make vector and __vector a keyword if LangOptions::AltiVec is set, and
>> if not followed by a numeric type keyword, treat it as an identifier.
>> My guess is that A is better as it involves less fixing up of cases where
>> an identifier with the name of "vector" can occur.
>>
>
> I don't know how much magic is inherent in this language extension.  Would
> it be bad to to make __vector *always* be on when AltiVec is enabled
> (whether or not it is followed by a 'numeric type keyword')?  We could then
> make 'vector' be fuzzier.  I'm still vaguely uncomfortable with 'vector'
> changing semantics depending on its lexical context, but understand that you
> probably don't have a choice here :)
>
>
>
>> 2. Regarding the typing, I'm thinking internally it would be treated just
>> as if __attribute__((vector_size(16)) were applied to the type, right?
>>
>
> Sure, if that works!  I don't know what __vector does.
>
>
> 3. With __attribute__((vector_size(16)), does the Clang code generation
>> already output everything LLVM needs to support the Altivec vectors?
>>
>
> I think so, though we also need an 'altivec.h' for clang to use, in a
> similar spirit to 'xmmintrin.h' for sse.
>
>
> For example, in looking at the code generated for some code using an
>> "__attribute__((vector_size(16)) float" variable or return type, the .ll
>> file uses "<4 x float>".  On a PowerPC platform supporting Altivec, does
>> LLVM automatically know to map that to a vector register?
>>
>
> Yes.  However, noone has done any ABI compatibility testing on PowerPC,
> even for simple types.  It is likely that there are a bunch of bugs passing
> structures by value etc.  Daniel has a nice randomized testcase generator
> for finding cases that need to be improved.
>
>
>> 4.  I'm guessing the Altivec functions can be implemented as Clang
>> built-in functions that map to calls to LLVM's altivec intrinsic functions,
>> right?  I haven't researched this much yet.
>>
>
> Yes, we support the 'unusual' altivec builtins in llvm-gcc  by mapping them
> onto the LLVM intrinsics in llvm/include/llvm/IntrinsicsPowerPC.td.  The
> simple ones make directly onto llvm IR vector instructions.
>
> -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/20091208/7e52ff6e/attachment.html 

From clattner at apple.com  Tue Dec  8 13:36:50 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 8 Dec 2009 11:36:50 -0800
Subject: [cfe-dev] Implementing Altivec vector support questions
In-Reply-To: <aad8390912081130t70275042yca27f59117ac6099@mail.gmail.com>
References: <aad8390912071255u6edde8c1v3ef6cda0b2e93ad@mail.gmail.com>
	<6E5AF218-DC8A-45D8-9DA7-B527CE549164@apple.com>
	<aad8390912081130t70275042yca27f59117ac6099@mail.gmail.com>
Message-ID: <CE9696AA-C266-4F1A-8EAF-EFF370D68647@apple.com>


On Dec 8, 2009, at 11:30 AM, John Thompson wrote:

> Thanks, Chris.
>
> I don't know how much magic is inherent in this language extension.   
> Would it be bad to to make __vector *always* be on when AltiVec is  
> enabled (whether or not it is followed by a 'numeric type  
> keyword')?  We could then make 'vector' be fuzzier.  I'm still  
> vaguely uncomfortable with 'vector' changing semantics depending on  
> its lexical context, but understand that you probably don't have a  
> choice here :)
>
> I think I see.  Treat "__vector" as a normal keyword token, and if  
> "vector" is encountered, I still do the context check and  
> effectively treat it as "__vector"?

Right.

>
> Sure, if that works!  I don't know what __vector does.
>
> My understanding is that "__vector" (or "vector") in this context is  
> always followed by a numeric type, i.e. "_vector unsigned int".  My  
> guess was that this would be effecticvely equivalent to  
> "__attribute__((vector_size(16))) unsigned int", so the plan would  
> then be to have the resulting type for these two be the same after  
> the semantic action.

so 'vector' doesn't work as a type qualifier?  For others type  
qualifiers, you can arrange them, e.g. "const int" == "int const" etc.

> I think so, though we also need an 'altivec.h' for clang to use, in  
> a similar spirit to 'xmmintrin.h' for sse.
>
> Yes, probably, if nothing else just to be compatible with gcc.   
> (It's mentioned in the Altivec standard in section 2.6 of http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf) 
> .  I was told it was orginally deprecated, but then left in to help  
> with early implementation.  Looking at the one we have for the PS3  
> gcc compiler, it seems to be the PowerPC version, and mostly just  
> maps Altivec names to the "__builtin_*" functions.

Right.  Be aware that you can't just use the GCC version of the header  
(afaik).  The terms of the license I've seen are something to the  
effect of "this header is GPL unless it is compiled with GCC".  In any  
case, you wouldn't want to reuse it directly anyway, because you'd  
want to implement the 'simple' operations in terms of generic vector  
operations instead of builtins.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091208/7dda9c8c/attachment.html 

From nicola.gigante at gmail.com  Tue Dec  8 14:25:45 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Tue, 8 Dec 2009 21:25:45 +0100
Subject: [cfe-dev] Fix to the exception specifications type checking
Message-ID: <B2BE54AC-5B33-455F-A132-34BF2F200DDE@gmail.com>

Hello again!

Douglas pointed me to a FIXME comment in SemaExceptionSpec.cpp that would be interesting to fix. In practice this would allow the last line of test/SemaCXX/exception-spec.cpp to compile (it's commented now).

I don't know very well how are the various clang classes, types etc... (and I'm learning) so I ask some questions:

To fix this bug I need to modify the Sema::CheckSpecifiedExceptionType method to check if the specified type is the class that contains the exception specification itself.
How do I obtain this class name? I think an additional parameter from the caller is required. In this case the caller is Sema::GetTypeForDeclarator. So I think I could get the class from the Declarator object? How?

Thank you :)

Nicola




From dgregor at apple.com  Tue Dec  8 15:01:12 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 8 Dec 2009 13:01:12 -0800
Subject: [cfe-dev] Fix to the exception specifications type checking
In-Reply-To: <B2BE54AC-5B33-455F-A132-34BF2F200DDE@gmail.com>
References: <B2BE54AC-5B33-455F-A132-34BF2F200DDE@gmail.com>
Message-ID: <BF92DA12-952A-4A49-B1CA-626A90D0DD89@apple.com>


On Dec 8, 2009, at 12:25 PM, Nicola Gigante wrote:

> Hello again!
>
> Douglas pointed me to a FIXME comment in SemaExceptionSpec.cpp that  
> would be interesting to fix. In practice this would allow the last  
> line of test/SemaCXX/exception-spec.cpp to compile (it's commented  
> now).
>
> I don't know very well how are the various clang classes, types  
> etc... (and I'm learning) so I ask some questions:
>
> To fix this bug I need to modify the  
> Sema::CheckSpecifiedExceptionType method to check if the specified  
> type is the class that contains the exception specification itself.
> How do I obtain this class name? I think an additional parameter  
> from the caller is required. In this case the caller is  
> Sema::GetTypeForDeclarator. So I think I could get the class from  
> the Declarator object? How?


There's an easier way to tell if a type is being defined. RecordType  
has an isBeingDefined() function that will tell you if that type is  
currently being defined.

	- Doug

From nicola.gigante at gmail.com  Tue Dec  8 16:22:58 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Tue, 8 Dec 2009 23:22:58 +0100
Subject: [cfe-dev] Fix to the exception specifications type checking
In-Reply-To: <BF92DA12-952A-4A49-B1CA-626A90D0DD89@apple.com>
References: <B2BE54AC-5B33-455F-A132-34BF2F200DDE@gmail.com>
	<BF92DA12-952A-4A49-B1CA-626A90D0DD89@apple.com>
Message-ID: <65C05E89-27FE-4C5E-AD47-F7B5CB24BDF5@gmail.com>


Il giorno 08/dic/2009, alle ore 22.01, Douglas Gregor ha scritto:

> 
> There's an easier way to tell if a type is being defined. RecordType has an isBeingDefined() function that will tell you if that type is currently being defined.
> 

Thanks! Then the patch is very easy, you find it attached. I've also uncommented that line in the test exception-spec.cpp. At least this is a try, because I'm not sure about a detail. Suppose we have a nested class that contains a method that throws the outer class:

class A {
   class B {
      void f() throw(A);
   };
};

Is this legal? If it is, no problem.

If it isn't, my patch doesn't do the job because isBeingDefined() still returns true.

Nicola

-------------- next part --------------
A non-text attachment was scrubbed...
Name: core-issue-437.patch
Type: application/octet-stream
Size: 1548 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091208/48947d96/attachment.obj 

From nicola.gigante at gmail.com  Tue Dec  8 17:05:03 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Wed, 9 Dec 2009 00:05:03 +0100
Subject: [cfe-dev] Fix to the exception specifications type checking
In-Reply-To: <ed4b3fb80912081437g5e20930ej1491d00b03c470c3@mail.gmail.com>
References: <B2BE54AC-5B33-455F-A132-34BF2F200DDE@gmail.com>
	<BF92DA12-952A-4A49-B1CA-626A90D0DD89@apple.com>
	<65C05E89-27FE-4C5E-AD47-F7B5CB24BDF5@gmail.com>
	<ed4b3fb80912081437g5e20930ej1491d00b03c470c3@mail.gmail.com>
Message-ID: <F1362D44-2C26-4C56-A0FC-2752D3613749@gmail.com>


Il giorno 08/dic/2009, alle ore 23.37, Sean Hunt ha scritto:

> 
> Looking at CWG Issue #437, it should be. It would probably be a good
> idea to add a testcase to make sure that works.
> 

Ok. Here is the same patch with a new testcase. I hope it's useful.

Bye bye,

Nicola

-------------- next part --------------
A non-text attachment was scrubbed...
Name: issue-437.patch
Type: application/octet-stream
Size: 1654 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091209/a7a2ffe0/attachment.obj 

From rideau3 at gmail.com  Tue Dec  8 23:21:55 2009
From: rideau3 at gmail.com (Sean Hunt)
Date: Tue, 08 Dec 2009 22:21:55 -0700
Subject: [cfe-dev] Hitting LexIdentifier with a minor performance hit
In-Reply-To: <5AAE4A37-B67C-4196-AF10-E540F7822FD3@apple.com>
References: <4B1973BC.7050406@gmail.com>
	<5AAE4A37-B67C-4196-AF10-E540F7822FD3@apple.com>
Message-ID: <4B1F33F3.8060302@gmail.com>

Chris Lattner wrote:
> On Dec 4, 2009, at 12:40 PM, Sean Hunt wrote:
> 
>> Hey,
>>
>> I'd like to split LexIdentifier into two functions so that the actual identifier lexing logic can be reused for user-defined literal suffixes. Since this is a change to the lexing code that will probably have a negative performance impact, however slight (one function call of overhead per identifier is added; one goto is removed per "nasty" identifier (a \, $, or ? is present)), I wanted to check it by first.
>>
>> The effective change is that the literal lexing code will be able to use LexIdentifierInternal to parse the suffix when I add that in.
> 
> This is one of the most performance sensitive pieces of the entire compiler.  Is there any other way to avoid this (e.g. through code duplication or macros)?  Have you measured the performance impact of this change?
> 
> -Chris

Output of 'time make test' without patch:

real    0m36.170s
user    0m21.965s
sys     0m10.453s

real    0m24.046s
user    0m22.269s
sys     0m9.789s

real    0m23.655s
user    0m22.085s
sys     0m10.157s

real    0m23.617s
user    0m21.821s
sys     0m10.113s

real    0m24.389s
user    0m22.213s
sys     0m10.029s

with patch:

real    0m26.394s
user    0m22.121s
sys     0m10.365s

real    0m24.502s
user    0m22.161s
sys     0m10.017s

real    0m24.139s
user    0m22.213s
sys     0m10.073s

real    0m23.997s
user    0m22.253s
sys     0m10.085s

real    0m23.894s
user    0m22.057s
sys     0m10.033s

Sean

From clattner at apple.com  Tue Dec  8 23:52:06 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 8 Dec 2009 21:52:06 -0800
Subject: [cfe-dev] Hitting LexIdentifier with a minor performance hit
In-Reply-To: <4B1F33F3.8060302@gmail.com>
References: <4B1973BC.7050406@gmail.com>
	<5AAE4A37-B67C-4196-AF10-E540F7822FD3@apple.com>
	<4B1F33F3.8060302@gmail.com>
Message-ID: <6F8F1818-E2C4-4586-8BAA-6A2C171F2120@apple.com>


On Dec 8, 2009, at 9:21 PM, Sean Hunt wrote:

> Chris Lattner wrote:
>> On Dec 4, 2009, at 12:40 PM, Sean Hunt wrote:
>> 
>>> Hey,
>>> 
>>> I'd like to split LexIdentifier into two functions so that the actual identifier lexing logic can be reused for user-defined literal suffixes. Since this is a change to the lexing code that will probably have a negative performance impact, however slight (one function call of overhead per identifier is added; one goto is removed per "nasty" identifier (a \, $, or ? is present)), I wanted to check it by first.
>>> 
>>> The effective change is that the literal lexing code will be able to use LexIdentifierInternal to parse the suffix when I add that in.
>> 
>> This is one of the most performance sensitive pieces of the entire compiler.  Is there any other way to avoid this (e.g. through code duplication or macros)?  Have you measured the performance impact of this change?
>> 
>> -Chris
> 
> Output of 'time make test' without patch:

make test isn't a very interesting way to test the performance of this, because it is dominated by other things.  Make sure you have a release-asserts build (do make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1) then do something like this:

clang -E -P somethinglarge.m -o out.mi (or .cpp)
time clang-cc -Eonly out.mi

-Chris



From filcab at gmail.com  Wed Dec  9 11:22:11 2009
From: filcab at gmail.com (Filipe Cabecinhas)
Date: Wed, 9 Dec 2009 17:22:11 +0000
Subject: [cfe-dev] Compiling emacs on Mac OS X
Message-ID: <e46c534c0912090922y195a95dbhc115432735d9c475@mail.gmail.com>

Hi all!

I'm trying to compile emacs on Mac OS X using clang but I may have hit a
bug...

clang on linux compiles it well (not exactly the same config, though).

clang on Mac OS X, compiling the console or the Cocoa version always creates
a defective temacs (something akin to a "stage 1 emacs"), which always blows
up with a Bus Error.

Any clues on how to approach this to find out what the bug is? One ideia
(from IRC) was to try compiling only one .c filewith clang... Anyone knows a
tool which tests the files one at the time? There are lots of .c linked in
temacs...

Regards,

  F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091209/130c4c52/attachment.html 

From mrs at apple.com  Wed Dec  9 12:40:56 2009
From: mrs at apple.com (Mike Stump)
Date: Wed, 9 Dec 2009 10:40:56 -0800
Subject: [cfe-dev] Compiling emacs on Mac OS X
In-Reply-To: <e46c534c0912090922y195a95dbhc115432735d9c475@mail.gmail.com>
References: <e46c534c0912090922y195a95dbhc115432735d9c475@mail.gmail.com>
Message-ID: <90257708-2444-40EC-91EF-9054FAA664DF@apple.com>

On Dec 9, 2009, at 9:22 AM, Filipe Cabecinhas wrote:
> clang on Mac OS X, compiling the console or the Cocoa version always creates a defective temacs (something akin to a "stage 1 emacs"), which always blows up with a Bus Error.

I suspect track these sorts of problems down by having two build trees, one with clang and one with gcc.  You can then copy *.o from gcc into the clang tree, finish building temacs, and then verify it works, if it works, you can then start binary stepping half of the .o files over and so on, until you whittle it down to a single (or a group) of .o files, that must be replaced by the files from gcc, inorder for temacs to work.  Usually, this process results in a single file.  That .ii is then the testcase.  Harder is to describe what about the file is bad.  To do that, I'd normally split the file into two bits, one compiled with clang and one compiled with gcc.  Again, binary search that code for the code that much be compiled by gcc for temacs to work, then, that cut down bit is the final testcase.

From filcab at gmail.com  Wed Dec  9 14:09:27 2009
From: filcab at gmail.com (Filipe Cabecinhas)
Date: Wed, 09 Dec 2009 20:09:27 +0000
Subject: [cfe-dev] Compiling emacs on Mac OS X
In-Reply-To: <90257708-2444-40EC-91EF-9054FAA664DF@apple.com>
References: <e46c534c0912090922y195a95dbhc115432735d9c475@mail.gmail.com>
	<90257708-2444-40EC-91EF-9054FAA664DF@apple.com>
Message-ID: <4B2003F7.1000701@gmail.com>

Hi.

I finally found the file: src/fns.c

I'll try reducing it with delta until I don't have a segfault and ping 
you back again.

Many thanks ;-)

   F

On 12/9/09 18:40, Mike Stump wrote:
> On Dec 9, 2009, at 9:22 AM, Filipe Cabecinhas wrote:
>> clang on Mac OS X, compiling the console or the Cocoa version always creates a defective temacs (something akin to a "stage 1 emacs"), which always blows up with a Bus Error.
>
> I suspect track these sorts of problems down by having two build trees, one with clang and one with gcc.  You can then copy *.o from gcc into the clang tree, finish building temacs, and then verify it works, if it works, you can then start binary stepping half of the .o files over and so on, until you whittle it down to a single (or a group) of .o files, that must be replaced by the files from gcc, inorder for temacs to work.  Usually, this process results in a single file.  That .ii is then the testcase.  Harder is to describe what about the file is bad.  To do that, I'd normally split the file into two bits, one compiled with clang and one compiled with gcc.  Again, binary search that code for the code that much be compiled by gcc for temacs to work, then, that cut down bit is the final testcase.

From mailing-lists.jens at ayton.se  Wed Dec  9 16:05:06 2009
From: mailing-lists.jens at ayton.se (Jens Ayton)
Date: Wed, 9 Dec 2009 23:05:06 +0100
Subject: [cfe-dev] Implementing Altivec vector support questions
In-Reply-To: <CE9696AA-C266-4F1A-8EAF-EFF370D68647@apple.com>
References: <aad8390912071255u6edde8c1v3ef6cda0b2e93ad@mail.gmail.com>
	<6E5AF218-DC8A-45D8-9DA7-B527CE549164@apple.com>
	<aad8390912081130t70275042yca27f59117ac6099@mail.gmail.com>
	<CE9696AA-C266-4F1A-8EAF-EFF370D68647@apple.com>
Message-ID: <D32D2505-0993-4CD7-900D-2DB49EAC3610@ayton.se>

On Dec 8, 2009, at 20:36, Chris Lattner wrote:
> On Dec 8, 2009, at 11:30 AM, John Thompson wrote:
>> 
>>  
>> My understanding is that "__vector" (or "vector") in this context is always followed by a numeric type, i.e. "_vector unsigned int".  My guess was that this would be effecticvely equivalent to "__attribute__((vector_size(16))) unsigned int", so the plan would then be to have the resulting type for these two be the same after the semantic action.
> 
> so 'vector' doesn't work as a type qualifier?  For others type qualifiers, you can arrange them, e.g. "const int" == "int const" etc.

In GCC with -faltivec, vector does not work as a type qualifier, but __vector does.

#include <altivec.h>   // warning: ignoring <altivec.h> because "-faltivec" specified

int main (int argc, const char * argv[])
{
    vector int a;      // warning: unused variable 'a'
    int vector;        // warning: unused variable 'vector'
    int vector b;      // error: nested functions are disabled (thanks, gcc)
    
    __vector int c;    // warning: unused variable 'c'
    int __vector;      // warning: useless type name in empty declaration
    int __vector d;    // warning: unused variable 'd'
    
    return 0;
}


Without -faltivec, vector is defined as __vector and acts as a qualifier (so the above code compiles with six warnings).


-- 
Jens Ayton



From john.thompson.jtsoftware at gmail.com  Wed Dec  9 17:37:49 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Wed, 9 Dec 2009 15:37:49 -0800
Subject: [cfe-dev] Implementing Altivec vector support questions
In-Reply-To: <D32D2505-0993-4CD7-900D-2DB49EAC3610@ayton.se>
References: <aad8390912071255u6edde8c1v3ef6cda0b2e93ad@mail.gmail.com>
	<6E5AF218-DC8A-45D8-9DA7-B527CE549164@apple.com>
	<aad8390912081130t70275042yca27f59117ac6099@mail.gmail.com>
	<CE9696AA-C266-4F1A-8EAF-EFF370D68647@apple.com>
	<D32D2505-0993-4CD7-900D-2DB49EAC3610@ayton.se>
Message-ID: <aad8390912091537n15c72d31p9a939adfbb915872@mail.gmail.com>

The Altivec standard specifies that __vector comes first as a type
specifier, and is a keyword.  It also says that vector can be either a macro
or a context-sensitive keyword.  Having it be a macro, of course, is not a
good idea.  Which is probably why gcc (at least the PS3 version) does it the
context-sensitive way.  Thus __vector cannot be a declaration name, but
vector can.

On Wed, Dec 9, 2009 at 2:05 PM, Jens Ayton <mailing-lists.jens at ayton.se>wrote:

> On Dec 8, 2009, at 20:36, Chris Lattner wrote:
> > On Dec 8, 2009, at 11:30 AM, John Thompson wrote:
> >>
> >>
> >> My understanding is that "__vector" (or "vector") in this context is
> always followed by a numeric type, i.e. "_vector unsigned int".  My guess
> was that this would be effecticvely equivalent to
> "__attribute__((vector_size(16))) unsigned int", so the plan would then be
> to have the resulting type for these two be the same after the semantic
> action.
> >
> > so 'vector' doesn't work as a type qualifier?  For others type
> qualifiers, you can arrange them, e.g. "const int" == "int const" etc.
>
> In GCC with -faltivec, vector does not work as a type qualifier, but
> __vector does.
>
> #include <altivec.h>   // warning: ignoring <altivec.h> because "-faltivec"
> specified
>
> int main (int argc, const char * argv[])
> {
>    vector int a;      // warning: unused variable 'a'
>    int vector;        // warning: unused variable 'vector'
>    int vector b;      // error: nested functions are disabled (thanks, gcc)
>
>    __vector int c;    // warning: unused variable 'c'
>    int __vector;      // warning: useless type name in empty declaration
>    int __vector d;    // warning: unused variable 'd'
>
>    return 0;
> }
>
>
> Without -faltivec, vector is defined as __vector and acts as a qualifier
> (so the above code compiles with six warnings).
>
>
> --
> Jens Ayton
>
>


-- 
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/20091209/402f29fc/attachment.html 

From dgregor at apple.com  Wed Dec  9 19:28:09 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 9 Dec 2009 17:28:09 -0800
Subject: [cfe-dev] Fix to the exception specifications type checking
In-Reply-To: <F1362D44-2C26-4C56-A0FC-2752D3613749@gmail.com>
References: <B2BE54AC-5B33-455F-A132-34BF2F200DDE@gmail.com>
	<BF92DA12-952A-4A49-B1CA-626A90D0DD89@apple.com>
	<65C05E89-27FE-4C5E-AD47-F7B5CB24BDF5@gmail.com>
	<ed4b3fb80912081437g5e20930ej1491d00b03c470c3@mail.gmail.com>
	<F1362D44-2C26-4C56-A0FC-2752D3613749@gmail.com>
Message-ID: <4AF576F4-F34A-4388-B27E-D56630DFBDBF@apple.com>


On Dec 8, 2009, at 3:05 PM, Nicola Gigante wrote:

> 
> Il giorno 08/dic/2009, alle ore 23.37, Sean Hunt ha scritto:
> 
>> 
>> Looking at CWG Issue #437, it should be. It would probably be a good
>> idea to add a testcase to make sure that works.
>> 
> 
> Ok. Here is the same patch with a new testcase. I hope it's useful.

A couple comments:

+  // This check deals with core issue 437, when we have a member function of a
+  // class that throws the class itself.

It's nice to quote the actual standard text, so we don't have to refer to some other document when reading through this code, like below:

   // C++ 15.4p2: A type denoted in an exception-specification shall not denote
   //   an incomplete type.

+  if (T->isRecordType() && T->getAs<RecordType>()->isBeingDefined())
+	  return false;

Please uses spaces only (no tabs). 

There's another call to RequireCompleteType later in the function; you'll need to do a similar check there for pointers  or references to classes that are being defined.

	- Doug

From xinfinity_a at yahoo.com  Thu Dec 10 09:26:36 2009
From: xinfinity_a at yahoo.com (Alex)
Date: Thu, 10 Dec 2009 15:26:36 +0000 (UTC)
Subject: [cfe-dev] Define new pragma in Clang
Message-ID: <loom.20091210T160845-355@post.gmane.org>

Hi all,

I would like to ask whether you can provide some information or a link to any
documentation regarding the definition of custom pragma in Clang. I understand
that the steps are modifying the parser lib/Parse/ParsePragma.cpp, adding an
action in include/clang/Parse/Action.h and a handler in Sema. But it is not as
easy as it sounds.
What I want is to have a pragma in the *.cpp file:

#pragma optimizeLoop
for(int i=0 ....)

and to obtain the LLVM IR in the *.ll file:

bb1:                                           
  %0 = load i32* %i, align 4, !pragma !0     
...


!0 = metadata !{metadata !"optimizeLoop"}


From nicola.gigante at gmail.com  Thu Dec 10 10:42:33 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 10 Dec 2009 17:42:33 +0100
Subject: [cfe-dev] Fix to the exception specifications type checking
In-Reply-To: <4AF576F4-F34A-4388-B27E-D56630DFBDBF@apple.com>
References: <B2BE54AC-5B33-455F-A132-34BF2F200DDE@gmail.com>
	<BF92DA12-952A-4A49-B1CA-626A90D0DD89@apple.com>
	<65C05E89-27FE-4C5E-AD47-F7B5CB24BDF5@gmail.com>
	<ed4b3fb80912081437g5e20930ej1491d00b03c470c3@mail.gmail.com>
	<F1362D44-2C26-4C56-A0FC-2752D3613749@gmail.com>
	<4AF576F4-F34A-4388-B27E-D56630DFBDBF@apple.com>
Message-ID: <D5D26632-3E1C-434F-A2AB-B837C16D2F0B@gmail.com>


Il giorno 10/dic/2009, alle ore 02.28, Douglas Gregor ha scritto:

> 
> A couple comments:
> 
> +  // This check deals with core issue 437, when we have a member function of a
> +  // class that throws the class itself.
> 
> It's nice to quote the actual standard text, so we don't have to refer to some other document when reading through this code, like below:
> 
Ok, I've quoted the standard in the comment now.

> 
> Please uses spaces only (no tabs). 
Yes, sorry again, I think there are only spaces now.

> 
> There's another call to RequireCompleteType later in the function; you'll need to do a similar check there for pointers  or references to classes that are being defined.

Yes, I think a testcase is needed for that code path, too, so I've added it.

I think everything's ok now.

Thank you,

Nicola

-------------- next part --------------
A non-text attachment was scrubbed...
Name: issue-437.patch
Type: application/octet-stream
Size: 2450 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091210/1b39f9ef/attachment-0001.obj 

From abramobagnara at tin.it  Thu Dec 10 10:56:55 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Thu, 10 Dec 2009 17:56:55 +0100
Subject: [cfe-dev] Lexical scope for macro expansion
Message-ID: <4B212857.4020707@tin.it>


Is there any way from MacroExpands callback to reach current lexical scope?

What I'm trying to do is to detect if some identifiers in the macro body
is a known typedef id.


From clattner at apple.com  Thu Dec 10 11:37:51 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 10 Dec 2009 09:37:51 -0800
Subject: [cfe-dev] Lexical scope for macro expansion
In-Reply-To: <4B212857.4020707@tin.it>
References: <4B212857.4020707@tin.it>
Message-ID: <4A05C653-28D0-4BBD-A46D-7A7C5377117C@apple.com>


On Dec 10, 2009, at 8:56 AM, Abramo Bagnara wrote:

> 
> Is there any way from MacroExpands callback to reach current lexical scope?
> 
> What I'm trying to do is to detect if some identifiers in the macro body
> is a known typedef id.

Nope, there is no way to do this, because the lexer/preprocessor lives at a lower level (and macros can be used and defined in multiple contexts, and don't follow the grammar of the language).  However, given a typedef, you can tell if it came from a macro.

-Chris

From dgregor at apple.com  Thu Dec 10 12:17:58 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 10 Dec 2009 10:17:58 -0800
Subject: [cfe-dev] Fix to the exception specifications type checking
In-Reply-To: <D5D26632-3E1C-434F-A2AB-B837C16D2F0B@gmail.com>
References: <B2BE54AC-5B33-455F-A132-34BF2F200DDE@gmail.com>
	<BF92DA12-952A-4A49-B1CA-626A90D0DD89@apple.com>
	<65C05E89-27FE-4C5E-AD47-F7B5CB24BDF5@gmail.com>
	<ed4b3fb80912081437g5e20930ej1491d00b03c470c3@mail.gmail.com>
	<F1362D44-2C26-4C56-A0FC-2752D3613749@gmail.com>
	<4AF576F4-F34A-4388-B27E-D56630DFBDBF@apple.com>
	<D5D26632-3E1C-434F-A2AB-B837C16D2F0B@gmail.com>
Message-ID: <52AF8A4D-948D-406D-A5D0-81E6F0EBD0FC@apple.com>


On Dec 10, 2009, at 8:42 AM, Nicola Gigante wrote:

> 
> Il giorno 10/dic/2009, alle ore 02.28, Douglas Gregor ha scritto:
> 
>> 
>> A couple comments:
>> 
>> +  // This check deals with core issue 437, when we have a member function of a
>> +  // class that throws the class itself.
>> 
>> It's nice to quote the actual standard text, so we don't have to refer to some other document when reading through this code, like below:
>> 
> Ok, I've quoted the standard in the comment now.
> 
>> 
>> Please uses spaces only (no tabs). 
> Yes, sorry again, I think there are only spaces now.
> 
>> 
>> There's another call to RequireCompleteType later in the function; you'll need to do a similar check there for pointers  or references to classes that are being defined.
> 
> Yes, I think a testcase is needed for that code path, too, so I've added it.
> 
> I think everything's ok now.

Thanks! Committed here:

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

	- Doug

From abramobagnara at tin.it  Thu Dec 10 12:25:52 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Thu, 10 Dec 2009 19:25:52 +0100
Subject: [cfe-dev] Lexical scope for macro expansion
In-Reply-To: <4A05C653-28D0-4BBD-A46D-7A7C5377117C@apple.com>
References: <4B212857.4020707@tin.it>
	<4A05C653-28D0-4BBD-A46D-7A7C5377117C@apple.com>
Message-ID: <4B213D30.5030900@tin.it>

Il 10/12/2009 18:37, Chris Lattner ha scritto:
> 
> On Dec 10, 2009, at 8:56 AM, Abramo Bagnara wrote:
> 
>>
>> Is there any way from MacroExpands callback to reach current lexical scope?
>>
>> What I'm trying to do is to detect if some identifiers in the macro body
>> is a known typedef id.
> 
> Nope, there is no way to do this, because the lexer/preprocessor
> lives at a lower level (and macros can be used and defined in
> multiple contexts, and don't follow the grammar of the language).
> However, given a typedef, you can tell if it came from a macro.

Let see if I've understand correctly:

1) I collect macro bodies using MacroExpands callback

2) I collect the spelling locations for the NameLoc of each encountered
TypedefLoc

3) I scan the previously collected tokens of the macros body: if one of
them has the same location of one of that collected in step 2 I know for
sure that the macro body contains a typedef name

Right?

From daniel at zuster.org  Thu Dec 10 12:55:04 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 10 Dec 2009 10:55:04 -0800
Subject: [cfe-dev] Define new pragma in Clang
In-Reply-To: <loom.20091210T160845-355@post.gmane.org>
References: <loom.20091210T160845-355@post.gmane.org>
Message-ID: <6a8523d60912101055n128d221fyce8e7526c5b526a4@mail.gmail.com>

On Thu, Dec 10, 2009 at 7:26 AM, Alex <xinfinity_a at yahoo.com> wrote:
> Hi all,
>
> I would like to ask whether you can provide some information or a link to any
> documentation regarding the definition of custom pragma in Clang. I understand
> that the steps are modifying the parser lib/Parse/ParsePragma.cpp, adding an
> action in include/clang/Parse/Action.h and a handler in Sema. But it is not as
> easy as it sounds.

What exactly are you having trouble with? Generally the pragma parser
just handles the parsing logic of the pragma, and then calls a handler
in Sema which will mark some information in the AST (for example,
adding an attribute or setting a bit in the decl).

 - Daniel

> What I want is to have a pragma in the *.cpp file:
>
> #pragma optimizeLoop
> for(int i=0 ....)
>
> and to obtain the LLVM IR in the *.ll file:
>
> bb1:
> ?%0 = load i32* %i, align 4, !pragma !0
> ...
>
>
> !0 = metadata !{metadata !"optimizeLoop"}
>
> _______________________________________________
> 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 Dec 10 17:47:59 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 10 Dec 2009 15:47:59 -0800
Subject: [cfe-dev] Lexical scope for macro expansion
In-Reply-To: <4B213D30.5030900@tin.it>
References: <4B212857.4020707@tin.it>
	<4A05C653-28D0-4BBD-A46D-7A7C5377117C@apple.com>
	<4B213D30.5030900@tin.it>
Message-ID: <5D57CE1B-757D-4665-BCF1-EE55DA3D39B6@apple.com>


On Dec 10, 2009, at 10:25 AM, Abramo Bagnara wrote:

> Il 10/12/2009 18:37, Chris Lattner ha scritto:
>> 
>> On Dec 10, 2009, at 8:56 AM, Abramo Bagnara wrote:
>> 
>>> 
>>> Is there any way from MacroExpands callback to reach current lexical scope?
>>> 
>>> What I'm trying to do is to detect if some identifiers in the macro body
>>> is a known typedef id.
>> 
>> Nope, there is no way to do this, because the lexer/preprocessor
>> lives at a lower level (and macros can be used and defined in
>> multiple contexts, and don't follow the grammar of the language).
>> However, given a typedef, you can tell if it came from a macro.
> 
> Let see if I've understand correctly:
> 
> 1) I collect macro bodies using MacroExpands callback
> 
> 2) I collect the spelling locations for the NameLoc of each encountered
> TypedefLoc
> 
> 3) I scan the previously collected tokens of the macros body: if one of
> them has the same location of one of that collected in step 2 I know for
> sure that the macro body contains a typedef name
> 
> Right?

Sounds like it could work!  I don't know the real use case you're going for here though.

-Chris



From jacob.n.smith at intel.com  Thu Dec 10 18:50:59 2009
From: jacob.n.smith at intel.com (Smith, Jacob N)
Date: Thu, 10 Dec 2009 16:50:59 -0800
Subject: [cfe-dev] Predicated instruction sets.
Message-ID: <7F21537D1A866F47BF40FA7DA794B2984CD9B8EC53@orsmsx509.amr.corp.intel.com>

Does LLVM have support (middle and back end) for predicated instruction sets like Itanium?

-Jacob Smith.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091210/adfe4072/attachment.html 

From clattner at apple.com  Thu Dec 10 19:08:20 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 10 Dec 2009 17:08:20 -0800
Subject: [cfe-dev] Predicated instruction sets.
In-Reply-To: <7F21537D1A866F47BF40FA7DA794B2984CD9B8EC53@orsmsx509.amr.corp.intel.com>
References: <7F21537D1A866F47BF40FA7DA794B2984CD9B8EC53@orsmsx509.amr.corp.intel.com>
Message-ID: <F87FCEA9-B59C-412D-BEC6-76694DA71333@apple.com>


On Dec 10, 2009, at 4:50 PM, Smith, Jacob N wrote:

> Does LLVM have support (middle and back end) for predicated instruction sets like Itanium?
>  

Yes, the arm backend supports and generates predicated instructions.

-Chris

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

From abramobagnara at tin.it  Fri Dec 11 03:11:37 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri, 11 Dec 2009 10:11:37 +0100
Subject: [cfe-dev] Lexical scope for macro expansion
In-Reply-To: <5D57CE1B-757D-4665-BCF1-EE55DA3D39B6@apple.com>
References: <4B212857.4020707@tin.it>
	<4A05C653-28D0-4BBD-A46D-7A7C5377117C@apple.com>
	<4B213D30.5030900@tin.it>
	<5D57CE1B-757D-4665-BCF1-EE55DA3D39B6@apple.com>
Message-ID: <4B220CC9.70503@tin.it>

Il 11/12/2009 00:47, Chris Lattner ha scritto:
> 
> On Dec 10, 2009, at 10:25 AM, Abramo Bagnara wrote:
> 
>> Il 10/12/2009 18:37, Chris Lattner ha scritto:
>>>
>>> On Dec 10, 2009, at 8:56 AM, Abramo Bagnara wrote:
>>>
>>>>
>>>> Is there any way from MacroExpands callback to reach current lexical scope?
>>>>
>>>> What I'm trying to do is to detect if some identifiers in the macro body
>>>> is a known typedef id.
>>>
>>> Nope, there is no way to do this, because the lexer/preprocessor
>>> lives at a lower level (and macros can be used and defined in
>>> multiple contexts, and don't follow the grammar of the language).
>>> However, given a typedef, you can tell if it came from a macro.
>>
>> Let see if I've understand correctly:
>>
>> 1) I collect macro bodies using MacroExpands callback
>>
>> 2) I collect the spelling locations for the NameLoc of each encountered
>> TypedefLoc
>>
>> 3) I scan the previously collected tokens of the macros body: if one of
>> them has the same location of one of that collected in step 2 I know for
>> sure that the macro body contains a typedef name
>>
>> Right?
> 
> Sounds like it could work!  I don't know the real use case you're going for here though.

Just suppose we want something that warn the user that:

typedef intptr_t Handle;

is preferred to:

#define Handle intptr_t

From andy at andrewprice.me.uk  Sat Dec 12 10:13:33 2009
From: andy at andrewprice.me.uk (Andrew Price)
Date: Sat, 12 Dec 2009 16:13:33 +0000
Subject: [cfe-dev] Finding redundant #includes
Message-ID: <20091212161332.GB13534@diogenes.swan.home>

Hi,

Can clang's analysis features help me find #includes which are no longer
required in a C source file? I'm working on cleaning up some old crufty
code and it would be good to have this functionality.

Andrew

From snaroff at apple.com  Sat Dec 12 10:51:00 2009
From: snaroff at apple.com (steve naroff)
Date: Sat, 12 Dec 2009 11:51:00 -0500
Subject: [cfe-dev] Finding redundant #includes
In-Reply-To: <20091212161332.GB13534@diogenes.swan.home>
References: <20091212161332.GB13534@diogenes.swan.home>
Message-ID: <BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>

Hi Andrew,

I don't believe we currently have such a feature (though it's an  
interesting idea).

Implementing this wouldn't be too difficult, however it certainly  
isn't a "quick hack".

snaroff

On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:

> Hi,
>
> Can clang's analysis features help me find #includes which are no  
> longer
> required in a C source file? I'm working on cleaning up some old  
> crufty
> code and it would be good to have this functionality.
>
> Andrew
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From andy at andrewprice.me.uk  Sat Dec 12 11:42:46 2009
From: andy at andrewprice.me.uk (Andrew Price)
Date: Sat, 12 Dec 2009 17:42:46 +0000
Subject: [cfe-dev] Finding redundant #includes
In-Reply-To: <BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>
References: <20091212161332.GB13534@diogenes.swan.home>
	<BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>
Message-ID: <20091212174246.GC13534@diogenes.swan.home>

On Sat, Dec 12, 2009 at 11:51:00AM -0500, steve naroff wrote:
> Hi Andrew,
> 
> I don't believe we currently have such a feature (though it's an
> interesting idea).
> 
> Implementing this wouldn't be too difficult, however it certainly
> isn't a "quick hack".

Sounds promising. I'm in no rush so if anybody would like me to test
patches for this feel free to send them my way.

Thanks,

Andrew

From nicola.gigante at gmail.com  Sat Dec 12 13:38:57 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sat, 12 Dec 2009 20:38:57 +0100
Subject: [cfe-dev] Fixing semantic diagnostics that embed english words
Message-ID: <BF2C8F7A-0E63-4215-809B-8435CDD759C5@gmail.com>

Hello,

I'm sending a patch that fixes some diagnostic messages that used to embed english words as arguments.
Previously, those string were flying around the various Sema*.cpp files as a const char *Flavor argument passed
to the DiagnoseAssignmentResult() method and a couple of others.

I've replaced those strings with values from an AssignmentAction enumeration declared in Sema.h around line 830. Is it ok to do things like that? The constants' name of the enumeration are very similar to the strings that they represents.

In the meantime, I've found that a similar Flavor argument was passed to BuildCXXDerivedToBaseExpr() method but that it wasn't used anywhere so I've removed it, is it ok?

I've run the tests and everything seems ok.

I hope this is useful, bye bye,

Nicola

-------------- next part --------------
A non-text attachment was scrubbed...
Name: diag_assignment_messages.patch
Type: application/octet-stream
Size: 31851 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091212/5ce35681/attachment-0001.obj 

From kremenek at apple.com  Sat Dec 12 13:56:40 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Sat, 12 Dec 2009 11:56:40 -0800
Subject: [cfe-dev] Finding redundant #includes
In-Reply-To: <BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>
References: <20091212161332.GB13534@diogenes.swan.home>
	<BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>
Message-ID: <43245090-B5BC-44F3-BBCE-4C4BA494BDD7@apple.com>

Doing it correctly wouldn't be too hard from the AST perspective, but would be tricky when considering preprocessor logic.  Any macros defined in a header and later used outside that header causes a dependency.  Moreover, if a file can be compiled under different contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc., then the "liveness" of a #include can change between translations.

On Dec 12, 2009, at 8:51 AM, steve naroff wrote:

> Hi Andrew,
> 
> I don't believe we currently have such a feature (though it's an  
> interesting idea).
> 
> Implementing this wouldn't be too difficult, however it certainly  
> isn't a "quick hack".
> 
> snaroff
> 
> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
> 
>> Hi,
>> 
>> Can clang's analysis features help me find #includes which are no  
>> longer
>> required in a C source file? I'm working on cleaning up some old  
>> crufty
>> code and it would be good to have this functionality.
>> 
>> Andrew
>> _______________________________________________
>> 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



From snaroff at apple.com  Sat Dec 12 14:26:28 2009
From: snaroff at apple.com (steve naroff)
Date: Sat, 12 Dec 2009 15:26:28 -0500
Subject: [cfe-dev] Finding redundant #includes
In-Reply-To: <43245090-B5BC-44F3-BBCE-4C4BA494BDD7@apple.com>
References: <20091212161332.GB13534@diogenes.swan.home>
	<BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>
	<43245090-B5BC-44F3-BBCE-4C4BA494BDD7@apple.com>
Message-ID: <5DFC6EDC-F18E-4FFF-AD08-86E97F5E8067@apple.com>

Good points. I think the diagnostics would need some interpretation  
(by a human).

If we wanted to get "fancy", we could devise some way to determine if  
a declaration occurred within a #ifdef clause (special casing the  
#ifndef that is commonly at the begin/end of every C header).  
Unfortunately, any feature involving the preprocessor is usually more  
complex than it should be (given the ability to arbitrary mutate  
headers in different contexts...including the same compilation unit:-(

Fortunately, ObjC headers and user-defined (i.e. non-system) headers  
usually aren't as gross...

snaroff

On Dec 12, 2009, at 2:56 PM, Ted Kremenek wrote:

> Doing it correctly wouldn't be too hard from the AST perspective,  
> but would be tricky when considering preprocessor logic.  Any macros  
> defined in a header and later used outside that header causes a  
> dependency.  Moreover, if a file can be compiled under different  
> contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc.,  
> then the "liveness" of a #include can change between translations.
>
> On Dec 12, 2009, at 8:51 AM, steve naroff wrote:
>
>> Hi Andrew,
>>
>> I don't believe we currently have such a feature (though it's an
>> interesting idea).
>>
>> Implementing this wouldn't be too difficult, however it certainly
>> isn't a "quick hack".
>>
>> snaroff
>>
>> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>>
>>> Hi,
>>>
>>> Can clang's analysis features help me find #includes which are no
>>> longer
>>> required in a C source file? I'm working on cleaning up some old
>>> crufty
>>> code and it would be good to have this functionality.
>>>
>>> Andrew
>>> _______________________________________________
>>> 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
>


From kremenek at apple.com  Sat Dec 12 15:01:51 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Sat, 12 Dec 2009 13:01:51 -0800
Subject: [cfe-dev] Finding redundant #includes
In-Reply-To: <5DFC6EDC-F18E-4FFF-AD08-86E97F5E8067@apple.com>
References: <20091212161332.GB13534@diogenes.swan.home>
	<BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>
	<43245090-B5BC-44F3-BBCE-4C4BA494BDD7@apple.com>
	<5DFC6EDC-F18E-4FFF-AD08-86E97F5E8067@apple.com>
Message-ID: <4EE5FDB3-03AD-444E-93D8-AF5CB6B9DE43@apple.com>

Just a thought: I wonder if for top-level #includes, one possibility is to remove the #include and see if it produces the same translation afterwards in the main source file.  That would avoid the issues with explicitly reasoning about preprocessor logic, and would (I believe) handle the simplest case that people care about.

On Dec 12, 2009, at 12:26 PM, steve naroff wrote:

> Good points. I think the diagnostics would need some interpretation (by a human).
> 
> If we wanted to get "fancy", we could devise some way to determine if a declaration occurred within a #ifdef clause (special casing the #ifndef that is commonly at the begin/end of every C header). Unfortunately, any feature involving the preprocessor is usually more complex than it should be (given the ability to arbitrary mutate headers in different contexts...including the same compilation unit:-(
> 
> Fortunately, ObjC headers and user-defined (i.e. non-system) headers usually aren't as gross...
> 
> snaroff
> 
> On Dec 12, 2009, at 2:56 PM, Ted Kremenek wrote:
> 
>> Doing it correctly wouldn't be too hard from the AST perspective, but would be tricky when considering preprocessor logic.  Any macros defined in a header and later used outside that header causes a dependency.  Moreover, if a file can be compiled under different contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc., then the "liveness" of a #include can change between translations.
>> 
>> On Dec 12, 2009, at 8:51 AM, steve naroff wrote:
>> 
>>> Hi Andrew,
>>> 
>>> I don't believe we currently have such a feature (though it's an
>>> interesting idea).
>>> 
>>> Implementing this wouldn't be too difficult, however it certainly
>>> isn't a "quick hack".
>>> 
>>> snaroff
>>> 
>>> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Can clang's analysis features help me find #includes which are no
>>>> longer
>>>> required in a C source file? I'm working on cleaning up some old
>>>> crufty
>>>> code and it would be good to have this functionality.
>>>> 
>>>> Andrew
>>>> _______________________________________________
>>>> 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
>> 
> 



From chandlerc at google.com  Sat Dec 12 16:14:47 2009
From: chandlerc at google.com (Chandler Carruth)
Date: Sat, 12 Dec 2009 14:14:47 -0800
Subject: [cfe-dev] Finding redundant #includes
In-Reply-To: <4EE5FDB3-03AD-444E-93D8-AF5CB6B9DE43@apple.com>
References: <20091212161332.GB13534@diogenes.swan.home>
	<BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>
	<43245090-B5BC-44F3-BBCE-4C4BA494BDD7@apple.com>
	<5DFC6EDC-F18E-4FFF-AD08-86E97F5E8067@apple.com>
	<4EE5FDB3-03AD-444E-93D8-AF5CB6B9DE43@apple.com>
Message-ID: <74c447500912121414y2dbef106xc82aedbb7862907c@mail.gmail.com>

On Sat, Dec 12, 2009 at 1:01 PM, Ted Kremenek <kremenek at apple.com> wrote:
> Just a thought: I wonder if for top-level #includes, one possibility is to remove the #include and see if it produces the same translation afterwards in the main source file. ?That would avoid the issues with explicitly reasoning about preprocessor logic, and would (I believe) handle the simplest case that people care about.

For reference, we do this and have found it be effective, especially
combined with a distributed compilation framework which can do even
the preprocessing phase
(http://google-opensource.blogspot.com/2008/08/distccs-pump-mode-new-design-for.html).
I'd be interested if there are less expensive ways to achieve these
results though.

>
> On Dec 12, 2009, at 12:26 PM, steve naroff wrote:
>
>> Good points. I think the diagnostics would need some interpretation (by a human).
>>
>> If we wanted to get "fancy", we could devise some way to determine if a declaration occurred within a #ifdef clause (special casing the #ifndef that is commonly at the begin/end of every C header). Unfortunately, any feature involving the preprocessor is usually more complex than it should be (given the ability to arbitrary mutate headers in different contexts...including the same compilation unit:-(
>>
>> Fortunately, ObjC headers and user-defined (i.e. non-system) headers usually aren't as gross...
>>
>> snaroff
>>
>> On Dec 12, 2009, at 2:56 PM, Ted Kremenek wrote:
>>
>>> Doing it correctly wouldn't be too hard from the AST perspective, but would be tricky when considering preprocessor logic. ?Any macros defined in a header and later used outside that header causes a dependency. ?Moreover, if a file can be compiled under different contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc., then the "liveness" of a #include can change between translations.
>>>
>>> On Dec 12, 2009, at 8:51 AM, steve naroff wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> I don't believe we currently have such a feature (though it's an
>>>> interesting idea).
>>>>
>>>> Implementing this wouldn't be too difficult, however it certainly
>>>> isn't a "quick hack".
>>>>
>>>> snaroff
>>>>
>>>> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Can clang's analysis features help me find #includes which are no
>>>>> longer
>>>>> required in a C source file? I'm working on cleaning up some old
>>>>> crufty
>>>>> code and it would be good to have this functionality.
>>>>>
>>>>> Andrew
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From xinfinity_a at yahoo.com  Sat Dec 12 17:13:13 2009
From: xinfinity_a at yahoo.com (Alex)
Date: Sat, 12 Dec 2009 23:13:13 +0000 (UTC)
Subject: [cfe-dev] Define new pragma in Clang
References: <loom.20091210T160845-355@post.gmane.org>
	<6a8523d60912101055n128d221fyce8e7526c5b526a4@mail.gmail.com>
Message-ID: <loom.20091213T000949-833@post.gmane.org>

Daniel Dunbar <daniel at ...> writes:


> What exactly are you having trouble with? Generally the pragma parser
> just handles the parsing logic of the pragma, and then calls a handler
> in Sema which will mark some information in the AST (for example,
> adding an attribute or setting a bit in the decl).
> 
>  - Daniel
> 
> > What I want is to have a pragma in the *.cpp file:
> >
> > #pragma optimizeLoop
> > for(int i=0 ....)
> >
> > and to obtain the LLVM IR in the *.ll file:
> >
> > bb1:
> > ?%0 = load i32* %i, align 4, !pragma !0
> > ...
> >
> >
> > !0 = metadata !{metadata !"optimizeLoop"}

My question is how can I attach the pragma to the following 'for' loop? What 
should I set in the AST such that I can translate it in the metadata in the LLVM 
IR?

Thank you.



From rahulgarg44 at gmail.com  Sun Dec 13 11:28:13 2009
From: rahulgarg44 at gmail.com (Rahul Garg)
Date: Sun, 13 Dec 2009 12:28:13 -0500
Subject: [cfe-dev] Newbie question : instrumenting code
Message-ID: <ad0cc6f00912130928o291f9cdco9a5f962f87f2a44c@mail.gmail.com>

Hi.

I am new to Clang and somewhat new to LLVM. I am doing a project where I
need to instrument C code to add some profiling information such as timers
and iteration counts of loops to some of the functions and then it will be
compiled using clang+llvm. The transformation need not be source to source.
All I am looking for is the ability to add instrumentation at some point
during the compilation process. Is it reasonable to attempt to modify Clang
so that it adds timers and logging calls at the places I need? Or should I
be looking at some other part of the LLVM stack?

thanks,
rahul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091213/85c00746/attachment.html 

From kremenek at apple.com  Sun Dec 13 12:56:50 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Sun, 13 Dec 2009 10:56:50 -0800
Subject: [cfe-dev] announcement: summer internship in Apple's Clang team
Message-ID: <C834CC32-B986-4FF2-89EB-AD68C7FB2097@apple.com>

[Brief internship announcement]

Apple's Clang team has an open position for a summer developer internship.  This team works both on the Clang frontend as well as Clang-based technologies (e.g., the Clang Static Analyzer).  During the internship, the individual would work directly with members of Apple's compiler team as well as the open source community to help develop Clang and future Apple products by actively coding and helping to set the directions for future Clang development.  Candidates should have relatively strong C++ skills, with existing knowledge of Clang/LLVM a plus.  If you are interested in applying, please email me a brief statement of interest and attach your resume/CV in PDF or raw text form (no MS Word documents please).

From dgregor at apple.com  Sun Dec 13 14:37:31 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Sun, 13 Dec 2009 12:37:31 -0800
Subject: [cfe-dev] Fixing semantic diagnostics that embed english words
In-Reply-To: <BF2C8F7A-0E63-4215-809B-8435CDD759C5@gmail.com>
References: <BF2C8F7A-0E63-4215-809B-8435CDD759C5@gmail.com>
Message-ID: <9B3CD7D8-A465-4EFA-B4F4-4082713BCFD1@apple.com>


On Dec 12, 2009, at 11:38 AM, Nicola Gigante wrote:

> Hello,
> 
> I'm sending a patch that fixes some diagnostic messages that used to embed english words as arguments.
> Previously, those string were flying around the various Sema*.cpp files as a const char *Flavor argument passed
> to the DiagnoseAssignmentResult() method and a couple of others.
> 
> I've replaced those strings with values from an AssignmentAction enumeration declared in Sema.h around line 830. Is it ok to do things like that? The constants' name of the enumeration are very similar to the strings that they represents.

Yes, this is very helpful! We generally prefix enumerator names with something resembling the enumeration name, so that we're less likely to have conflicts. For example, in the names here:

+  enum AssignmentAction {
+    Assigning,
+    Copying,
+    Passing,
+    Returning,
+    Converting,
+    Initializing,
+    Sending,
+    Casting
+  };

we would prefer to use the names AA_Assigning, AA_Copying, AA_Passing, etc.

> In the meantime, I've found that a similar Flavor argument was passed to BuildCXXDerivedToBaseExpr() method but that it wasn't used anywhere so I've removed it, is it ok?

Yes, thanks!

Thank you for fixing this; if you could perform the rename mentioned above, I'd be happy to commit your patch.

	- Doug

From nicola.gigante at gmail.com  Sun Dec 13 15:43:19 2009
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sun, 13 Dec 2009 22:43:19 +0100
Subject: [cfe-dev] Fixing semantic diagnostics that embed english words
In-Reply-To: <9B3CD7D8-A465-4EFA-B4F4-4082713BCFD1@apple.com>
References: <BF2C8F7A-0E63-4215-809B-8435CDD759C5@gmail.com>
	<9B3CD7D8-A465-4EFA-B4F4-4082713BCFD1@apple.com>
Message-ID: <E9DB49A4-0754-4C4E-B4B2-4C092D9CAB58@gmail.com>


Il giorno 13/dic/2009, alle ore 21.37, Douglas Gregor ha scritto:

> 
> Thank you for fixing this; if you could perform the rename mentioned above, I'd be happy to commit your patch.
> 

Here it is :)

> 	- Doug

Nicola

-------------- next part --------------
A non-text attachment was scrubbed...
Name: diag_assignment_messages.patch
Type: application/octet-stream
Size: 31897 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091213/bcc39116/attachment-0001.obj 

From fjahanian at apple.com  Mon Dec 14 11:38:40 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Mon, 14 Dec 2009 09:38:40 -0800
Subject: [cfe-dev] clang-cc no more
In-Reply-To: <9B3CD7D8-A465-4EFA-B4F4-4082713BCFD1@apple.com>
References: <BF2C8F7A-0E63-4215-809B-8435CDD759C5@gmail.com>
	<9B3CD7D8-A465-4EFA-B4F4-4082713BCFD1@apple.com>
Message-ID: <D558A1D1-72CE-454E-A8E9-F40D6E480DDC@apple.com>

Hi All,

Make sure to remove clang-cc from you path when testing. Not all tests  
have been converted to
use 'clang -cc1...'.  I am modifying all objc test now.

- Fariborz


From andy at andrewprice.me.uk  Mon Dec 14 15:45:06 2009
From: andy at andrewprice.me.uk (Andrew Price)
Date: Mon, 14 Dec 2009 21:45:06 +0000
Subject: [cfe-dev] Finding redundant #includes
In-Reply-To: <20091212161332.GB13534@diogenes.swan.home>
References: <20091212161332.GB13534@diogenes.swan.home>
Message-ID: <20091214214505.GE13534@diogenes.swan.home>

I have opened a bug to track this feature request:

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

Andrew

From daniel at zuster.org  Mon Dec 14 19:56:38 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Mon, 14 Dec 2009 17:56:38 -0800
Subject: [cfe-dev] Define new pragma in Clang
In-Reply-To: <loom.20091213T000949-833@post.gmane.org>
References: <loom.20091210T160845-355@post.gmane.org>
	<6a8523d60912101055n128d221fyce8e7526c5b526a4@mail.gmail.com>
	<loom.20091213T000949-833@post.gmane.org>
Message-ID: <6a8523d60912141756r6a6b3b29h8235b8dc440dbb88@mail.gmail.com>

On Sat, Dec 12, 2009 at 3:13 PM, Alex <xinfinity_a at yahoo.com> wrote:
> Daniel Dunbar <daniel at ...> writes:
>
>
>> What exactly are you having trouble with? Generally the pragma parser
>> just handles the parsing logic of the pragma, and then calls a handler
>> in Sema which will mark some information in the AST (for example,
>> adding an attribute or setting a bit in the decl).
>>
>> ?- Daniel
>>
>> > What I want is to have a pragma in the *.cpp file:
>> >
>> > #pragma optimizeLoop
>> > for(int i=0 ....)
>> >
>> > and to obtain the LLVM IR in the *.ll file:
>> >
>> > bb1:
>> > ?%0 = load i32* %i, align 4, !pragma !0
>> > ...
>> >
>> >
>> > !0 = metadata !{metadata !"optimizeLoop"}
>
> My question is how can I attach the pragma to the following 'for' loop? What
> should I set in the AST such that I can translate it in the metadata in the LLVM
> IR?

Generally you would need to do something like:
 1. Add a pragma handler, which has a callback on the actions interface.
 2. Add a sema implementation of the callback, which sets some
internal bit in the Sema object.
 3. Add a new bit to the 'for' statement, to specify whether this it
had #pragma optimize set.
 4. Modify codegin to emit the metadata based on that bit.

 - Daniel

> Thank you.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From daniel at zuster.org  Mon Dec 14 20:21:03 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Mon, 14 Dec 2009 18:21:03 -0800
Subject: [cfe-dev] clang-cc is gone
Message-ID: <6a8523d60912141821gaa94d9kb6d7d745a561405b@mail.gmail.com>

(resending for visibility beyond cfe-commits)

clang-cc has been removed, for sanity you should probably remove any
copies you find lying around in your development trees. It has been
replaced by 'clang -cc1', so both tools are in a single executable.

clang (the driver) still calls clang -cc1 (the frontend) during
compilation, so don't expect gdb/shark on clang to work differently,
yet.

 - Daniel

From daniel at zuster.org  Mon Dec 14 20:27:59 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Mon, 14 Dec 2009 18:27:59 -0800
Subject: [cfe-dev] Finding redundant #includes
In-Reply-To: <4EE5FDB3-03AD-444E-93D8-AF5CB6B9DE43@apple.com>
References: <20091212161332.GB13534@diogenes.swan.home>
	<BC263299-B0C3-4B4F-A312-A486F4F50402@apple.com>
	<43245090-B5BC-44F3-BBCE-4C4BA494BDD7@apple.com>
	<5DFC6EDC-F18E-4FFF-AD08-86E97F5E8067@apple.com>
	<4EE5FDB3-03AD-444E-93D8-AF5CB6B9DE43@apple.com>
Message-ID: <6a8523d60912141827o51441ed3l9a245c6a1b9b7d14@mail.gmail.com>

On Sat, Dec 12, 2009 at 1:01 PM, Ted Kremenek <kremenek at apple.com> wrote:
> Just a thought: I wonder if for top-level #includes, one possibility is to remove the #include and see if it produces the same translation afterwards in the main source file. ?That would avoid the issues with explicitly reasoning about preprocessor logic, and would (I believe) handle the simplest case that people care about.

Yes, I think this would be a sane and pretty strong approach. It
requires a good way to compare ASTs, which we don't have.

There is a lot of utility in removing includes in non-main fails, as
well, of course.

 - Daniel

> On Dec 12, 2009, at 12:26 PM, steve naroff wrote:
>
>> Good points. I think the diagnostics would need some interpretation (by a human).
>>
>> If we wanted to get "fancy", we could devise some way to determine if a declaration occurred within a #ifdef clause (special casing the #ifndef that is commonly at the begin/end of every C header). Unfortunately, any feature involving the preprocessor is usually more complex than it should be (given the ability to arbitrary mutate headers in different contexts...including the same compilation unit:-(
>>
>> Fortunately, ObjC headers and user-defined (i.e. non-system) headers usually aren't as gross...
>>
>> snaroff
>>
>> On Dec 12, 2009, at 2:56 PM, Ted Kremenek wrote:
>>
>>> Doing it correctly wouldn't be too hard from the AST perspective, but would be tricky when considering preprocessor logic. ?Any macros defined in a header and later used outside that header causes a dependency. ?Moreover, if a file can be compiled under different contexts, e.g., on Mac OS X one can compile for i386, x86_64, etc., then the "liveness" of a #include can change between translations.
>>>
>>> On Dec 12, 2009, at 8:51 AM, steve naroff wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> I don't believe we currently have such a feature (though it's an
>>>> interesting idea).
>>>>
>>>> Implementing this wouldn't be too difficult, however it certainly
>>>> isn't a "quick hack".
>>>>
>>>> snaroff
>>>>
>>>> On Dec 12, 2009, at 11:13 AM, Andrew Price wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Can clang's analysis features help me find #includes which are no
>>>>> longer
>>>>> required in a C source file? I'm working on cleaning up some old
>>>>> crufty
>>>>> code and it would be good to have this functionality.
>>>>>
>>>>> Andrew
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>
>
> _______________________________________________
> 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 Dec 15 10:43:43 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Tue, 15 Dec 2009 08:43:43 -0800
Subject: [cfe-dev] clang-cc is gone
In-Reply-To: <6a8523d60912141821gaa94d9kb6d7d745a561405b@mail.gmail.com>
References: <6a8523d60912141821gaa94d9kb6d7d745a561405b@mail.gmail.com>
Message-ID: <aad8390912150843x23f900a8qa2472bb172e1ffac@mail.gmail.com>

So to use the old clang-cc options, you use the -cc1 option?  I.e.:

clang-cc -faltivec -syntax-only Parser/ativec.c

becomes:

clang -cc1 -faltivec -syntax-only Parser/ativec.c
If so, you probably want to fix the --help option to show "-cc1", or
otherwise indicate how it is done.  Otherwise the only clue is the -Xclang
option, which I couldn't get to work.

Use:

clang -cc1 --help

to get the old options.

Are we moving to make the driver recognize the clang-cc options, or at least
those for which it makes sense?

The tests still seem to work, even though I removed clang-cc.exe.  Is the
test driver translating the clang-cc run lines?

The user guide could use some work to be more complete and formatted more
clearly with respect to the options.  If it's on no one's plate, I'd be
happy to help with that, once things are settled.

-John

On Mon, Dec 14, 2009 at 6:21 PM, Daniel Dunbar <daniel at zuster.org> wrote:

> (resending for visibility beyond cfe-commits)
>
> clang-cc has been removed, for sanity you should probably remove any
> copies you find lying around in your development trees. It has been
> replaced by 'clang -cc1', so both tools are in a single executable.
>
> clang (the driver) still calls clang -cc1 (the frontend) during
> compilation, so don't expect gdb/shark on clang to work differently,
> yet.
>
>  - Daniel
> _______________________________________________
> 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/20091215/18a8907e/attachment.html 

From daniel at zuster.org  Tue Dec 15 12:48:28 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Tue, 15 Dec 2009 10:48:28 -0800
Subject: [cfe-dev] clang-cc is gone
In-Reply-To: <aad8390912150843x23f900a8qa2472bb172e1ffac@mail.gmail.com>
References: <6a8523d60912141821gaa94d9kb6d7d745a561405b@mail.gmail.com>
	<aad8390912150843x23f900a8qa2472bb172e1ffac@mail.gmail.com>
Message-ID: <6a8523d60912151048l7d37656bm37567bfe15f13c9f@mail.gmail.com>

On Tue, Dec 15, 2009 at 8:43 AM, John Thompson
<john.thompson.jtsoftware at gmail.com> wrote:
> So to use the old clang-cc options, you use the -cc1 option?? I.e.:
>
> clang-cc -faltivec -syntax-only Parser/ativec.c
>
> becomes:
>
> clang -cc1 -faltivec -syntax-only Parser/ativec.c

Correct.

> If so, you?probably want to fix the --help option to show "-cc1", or
> otherwise indicate how it is done.? Otherwise the only clue is the -Xclang
> option, which I couldn't get to work.

-cc1 is not a user feature, I actively don't want it in the help.
-Xclang is similarly only for developers. I will document them more in
the clang developer documentation at some point. -Xclang is hard to
use if you don't understand the driver, because the driver doesn't
"see" it, and it doesn't effect the driver actions.

> clang -cc1 --help
>
> to get the old options.
>
> Are we moving to make the driver recognize the clang-cc options, or at least
> those for which it makes sense?

Not actively. I am always hesitant to expose things from the driver
proper as it is tantamount to publicly supporting the feature which
raises the quality bar. If you have specific features you think should
be exposed, we should treat them on a case by case basis.

> The tests still seem to work, even though I removed clang-cc.exe.? Is the
> test driver translating the clang-cc run lines?

Yes, it has in fact always done this (to make the path absolute and
honor CLANGCC the environment variable). I will be rewriting the tests
to make this more obvious.

> The user guide could use some work to be more complete and formatted more
> clearly with respect to the options.? If it's on no one's plate, I'd be
> happy to help with that, once things are settled.

That would be awesome.

 - Daniel

> -John
>
> On Mon, Dec 14, 2009 at 6:21 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>>
>> (resending for visibility beyond cfe-commits)
>>
>> clang-cc has been removed, for sanity you should probably remove any
>> copies you find lying around in your development trees. It has been
>> replaced by 'clang -cc1', so both tools are in a single executable.
>>
>> clang (the driver) still calls clang -cc1 (the frontend) during
>> compilation, so don't expect gdb/shark on clang to work differently,
>> yet.
>>
>> ?- Daniel
>> _______________________________________________
>> 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 mrs at apple.com  Tue Dec 15 21:26:03 2009
From: mrs at apple.com (Mike Stump)
Date: Tue, 15 Dec 2009 19:26:03 -0800
Subject: [cfe-dev] -fcatch-undefined-behavior testing
Message-ID: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>

If people want to try a neat new feature, go ahead and compile your software with -fcatch-undefined-behavior and then test your software.  If there are any traps at runtime, investigate your code and see if it is trying to execute some undefined behavior.  See http://clang.llvm.org/docs/UsersManual.html#codegen for some details on the checks that are inserted.

Questions, comments, concerns...  let me know.  If it catches any real bugs, that'd be interesting to know.  If you find any bugs, I'd be interested in those as well.

From dgregor at apple.com  Tue Dec 15 21:53:09 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 15 Dec 2009 19:53:09 -0800
Subject: [cfe-dev] Fixing semantic diagnostics that embed english words
In-Reply-To: <E9DB49A4-0754-4C4E-B4B2-4C092D9CAB58@gmail.com>
References: <BF2C8F7A-0E63-4215-809B-8435CDD759C5@gmail.com>
	<9B3CD7D8-A465-4EFA-B4F4-4082713BCFD1@apple.com>
	<E9DB49A4-0754-4C4E-B4B2-4C092D9CAB58@gmail.com>
Message-ID: <91FE98B1-071C-41C5-B30D-E9448013644B@apple.com>


On Dec 13, 2009, at 1:43 PM, Nicola Gigante wrote:

> 
> Il giorno 13/dic/2009, alle ore 21.37, Douglas Gregor ha scritto:
> 
>> 
>> Thank you for fixing this; if you could perform the rename mentioned above, I'd be happy to commit your patch.
>> 
> 
> Here it is :)


Great, thanks! Committed here:

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

	- Doug

From wan at google.com  Tue Dec 15 21:55:18 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Tue, 15 Dec 2009 19:55:18 -0800
Subject: [cfe-dev] source file location in crash reports?
Message-ID: <89adf3280912151955laab6000s140616a758faaacb@mail.gmail.com>

Hi,

After we switched from clang-cc to 'clang -cc1', I noticed that the
crash message (when clang hits an assertion) no longer includes the
source file location of the symbol clang is parsing at the time of the
crash.  This makes it hard to find out which code snippet is choking
clang.

http://llvm.org/PR5793 has an example.

I wonder if this is related to the 'clang -cc1' switch and if it's
intended.  Can we get the old behavior back?  Thanks,

-- 
Zhanyong

From daniel at zuster.org  Wed Dec 16 05:39:01 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Wed, 16 Dec 2009 03:39:01 -0800
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
Message-ID: <6a8523d60912160339n72e439an10854ba1e37c2a2e@mail.gmail.com>

Very cool, I've long wanted this feature.

Have you considered running this on an LLVM nightly test run? That
might be a good way to flush out either undefined behavior in the
tests (which would be nice to fix) or bugs in the code.

 - Daniel

On Tue, Dec 15, 2009 at 7:26 PM, Mike Stump <mrs at apple.com> wrote:
> If people want to try a neat new feature, go ahead and compile your software with -fcatch-undefined-behavior and then test your software. ?If there are any traps at runtime, investigate your code and see if it is trying to execute some undefined behavior. ?See http://clang.llvm.org/docs/UsersManual.html#codegen for some details on the checks that are inserted.
>
> Questions, comments, concerns... ?let me know. ?If it catches any real bugs, that'd be interesting to know. ?If you find any bugs, I'd be interested in those as well.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From daniel at zuster.org  Wed Dec 16 05:45:04 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Wed, 16 Dec 2009 03:45:04 -0800
Subject: [cfe-dev] source file location in crash reports?
In-Reply-To: <89adf3280912151955laab6000s140616a758faaacb@mail.gmail.com>
References: <89adf3280912151955laab6000s140616a758faaacb@mail.gmail.com>
Message-ID: <6a8523d60912160345mf5481a0s8bbb61fbc36a26f2@mail.gmail.com>

Fixed in ~r91537.

 - Daniel

2009/12/15 Zhanyong Wan (?x.x x) <wan at google.com>:
> Hi,
>
> After we switched from clang-cc to 'clang -cc1', I noticed that the
> crash message (when clang hits an assertion) no longer includes the
> source file location of the symbol clang is parsing at the time of the
> crash. ?This makes it hard to find out which code snippet is choking
> clang.
>
> http://llvm.org/PR5793 has an example.
>
> I wonder if this is related to the 'clang -cc1' switch and if it's
> intended. ?Can we get the old behavior back? ?Thanks,
>
> --
> Zhanyong
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From edwintorok at gmail.com  Wed Dec 16 05:47:14 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Wed, 16 Dec 2009 13:47:14 +0200
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
Message-ID: <4B28C8C2.5050606@gmail.com>

On 2009-12-16 05:26, Mike Stump wrote:
> If people want to try a neat new feature, go ahead and compile your software with -fcatch-undefined-behavior and then test your software.  If there are any traps at runtime, investigate your code and see if it is trying to execute some undefined behavior.  See http://clang.llvm.org/docs/UsersManual.html#codegen for some details on the checks that are inserted.
>
> Questions, comments, concerns...  let me know.  If it catches any real bugs, that'd be interesting to know.  If you find any bugs, I'd be interested in those as well.

Hi,

This is a very interesting feature!

I tested it (after reverting r91380 locally) on ClamAV.
It found a shift > bitwidth error, and got a SIGILL. So far so good.

However I found no way to skip this error, to look for more errors.
Would it be possible to emit something else instead of __builtin_trap()?
Perhaps a debugger breakpoint, or something else that can be skipped.

Also would it be possible to warn about shift exceeding width only if
they can change the outcome?
Consider this code from ClamAV, which for b == 0 does a left shift by 32
on a 32-bit var:
#define CLI_ROR(a,b) a = (( a >> (b % (sizeof(a)<<3) ))  |  (a << ( 
(sizeof(a)<<3)  -  (b % (sizeof(a)<<3 )) ) ))

If the shift of 32 is implemented as shifting out all the bits, then the
result is a|0 -> a.
If the shift of 32 is implemented as a shift considering the low bits
only, then its a shift by 0, and the result is a|a -> a.
So regardless how the shift of 32 is implemented the outcome is a, right?
The intent of the macro is to emulate the x86 ror instruction, and both
llvm/gcc know to turn it into a ror when compiled
if b is constant. However neither knows to turn it into a ror if b is
not a constant...
The shift of 32 could be worked around by checking whether b is 0, but
that adds another branch.

Best regards,
--Edwin

From wan at google.com  Wed Dec 16 11:06:27 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Wed, 16 Dec 2009 09:06:27 -0800
Subject: [cfe-dev] source file location in crash reports?
In-Reply-To: <6a8523d60912160345mf5481a0s8bbb61fbc36a26f2@mail.gmail.com>
References: <89adf3280912151955laab6000s140616a758faaacb@mail.gmail.com> 
	<6a8523d60912160345mf5481a0s8bbb61fbc36a26f2@mail.gmail.com>
Message-ID: <89adf3280912160906u198c9b76s2f08dce918f52d4a@mail.gmail.com>

Great.  Thanks!

2009/12/16 Daniel Dunbar <daniel at zuster.org>:
> Fixed in ~r91537.
>
> ?- Daniel
>
> 2009/12/15 Zhanyong Wan (?x.x x) <wan at google.com>:
>> Hi,
>>
>> After we switched from clang-cc to 'clang -cc1', I noticed that the
>> crash message (when clang hits an assertion) no longer includes the
>> source file location of the symbol clang is parsing at the time of the
>> crash. ?This makes it hard to find out which code snippet is choking
>> clang.
>>
>> http://llvm.org/PR5793 has an example.
>>
>> I wonder if this is related to the 'clang -cc1' switch and if it's
>> intended. ?Can we get the old behavior back? ?Thanks,
>>
>> --
>> Zhanyong
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>



-- 
Zhanyong


From mrs at apple.com  Wed Dec 16 12:12:50 2009
From: mrs at apple.com (Mike Stump)
Date: Wed, 16 Dec 2009 10:12:50 -0800
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <6a8523d60912160339n72e439an10854ba1e37c2a2e@mail.gmail.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
	<6a8523d60912160339n72e439an10854ba1e37c2a2e@mail.gmail.com>
Message-ID: <C209EE67-D3F8-4A8D-B63C-A5E295719383@apple.com>

On Dec 16, 2009, at 3:39 AM, Daniel Dunbar wrote:
> Have you considered running this on an LLVM nightly test run?

Love to see the results; my email was to solicit others into trying the feature out on their favorite code.

Also, I guess I should say, if people have undefined behavior that they would just love to see runtime checks for, maybe to catch portability problems, or to catch security problems or just random bugs in code, I've love to hear the ideas.

From mrs at apple.com  Wed Dec 16 12:36:04 2009
From: mrs at apple.com (Mike Stump)
Date: Wed, 16 Dec 2009 10:36:04 -0800
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <4B28C8C2.5050606@gmail.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
	<4B28C8C2.5050606@gmail.com>
Message-ID: <6B6F2033-1BC1-44AA-BF2B-4B7A741DD41B@apple.com>

On Dec 16, 2009, at 3:47 AM, T?r?k Edwin wrote:
> This is a very interesting feature!

> However I found no way to skip this error, to look for more errors.

Yeah, limitation of the current codegen.  Trivially, one could imagine logging interface codegen.  It could include column and line numbers, filenames and what rule was violated and how (the shift amount was 128 bits).  I think filing a PR for a logging system would make a nice addition.  Great for large codebases when build test cycle times are in the 1-3 day range.

> Also would it be possible to warn about shift exceeding width only if they can change the outcome?

Well, the notion that some undefined behavior is defined and perfectly ok, is an odd notion.  Rather, think of it this way, the runtime check is trying to tell you that the `portable' version of ROR doesn't work on ppc and that you need to fix your code to be portable.  After it is fixed, there will be no runtime failure.  In fact, one of the purposes of the check was to find exactly this type of non-portable code.

> The shift of 32 could be worked around by checking whether b is 0, but that adds another branch.

A branch on a constant is relatively free.  A smart optimizer, having a ror instruction on the target, would always eliminate the branch as well.

Consider what happens when a is constant, and the emulation for shift at compile time doesn't match the runtime behavior of shift, the wrong value is computed.  Might not happen on a native compiler, but odds of this happening under cross compilation go up.

From edwintorok at gmail.com  Wed Dec 16 13:36:04 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Wed, 16 Dec 2009 21:36:04 +0200
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <6B6F2033-1BC1-44AA-BF2B-4B7A741DD41B@apple.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
	<4B28C8C2.5050606@gmail.com>
	<6B6F2033-1BC1-44AA-BF2B-4B7A741DD41B@apple.com>
Message-ID: <4B2936A4.7090802@gmail.com>

On 2009-12-16 20:36, Mike Stump wrote:
> On Dec 16, 2009, at 3:47 AM, T?r?k Edwin wrote:
>   
>> This is a very interesting feature!
>>     
>
>   
>> However I found no way to skip this error, to look for more errors.
>>     
>
> Yeah, limitation of the current codegen.  Trivially, one could imagine logging interface codegen.  It could include column and line numbers, filenames and what rule was violated and how (the shift amount was 128 bits).  I think filing a PR for a logging system would make a nice addition.  Great for large codebases when build test cycle times are in the 1-3 day range.
>   

Ok. As a short term solution could it generate an int3 though instead of
an illegal instruction?

>   
>> Also would it be possible to warn about shift exceeding width only if they can change the outcome?
>>     
>
> Well, the notion that some undefined behavior is defined and perfectly ok, is an odd notion.  Rather, think of it this way, the runtime check is trying to tell you that the `portable' version of ROR doesn't work on ppc and that you need to fix your code to be portable.  After it is fixed, there will be no runtime failure.  In fact, one of the purposes of the check was to find exactly this type of non-portable code.
>   

For the case where the shift amount is constant, I agree that it is
undefined, for (uint32_t x=...; x << 32) the compiler can say that x is
42 (or some other random value).

However when the shift amount is not constant, the compiler has no
choice but to implement the shift with CPU instructions (it may or may
not recognize the ror pattern, currently it doesn't).
In that case the undefined behavior for the shift becomes an
implementation defined behavior of the CPU.

For the CLI_ROR case, the only scenario where the undefined behavior
might occur (and I don't consider it a bug) is if shift amount == bitwidth,
in which case it depends on the CPU what happens
(X86 appears to shift by 0, PPC shifts all bits out and result is 0). In
either case the end result of the CLI_ROR macro is the same, since a|a
== a|0.

For higher shift amounts the result may not be the same, but I think for
shift amount == bitwidth the result is still correct.

Indeed when the rotate amount passes to CLI_ROR is greater than
bitwidth, that should be fixed, see here:
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1778

>   
>> The shift of 32 could be worked around by checking whether b is 0, but that adds another branch.
>>     
>
> A branch on a constant is relatively free.  A smart optimizer, having a ror instruction on the target, would always eliminate the branch as well.
>
> Consider what happens when a is constant, and the emulation for shift at compile time doesn't match the runtime behavior of shift, the wrong value is computed.  Might not happen on a native compiler, but odds of this happening under cross compilation go up.

Yeah the branch for the constant case would be fine, however it would
mean a penalty for the non-constant shift case.

Best regards,
--Edwin

From edwintorok at gmail.com  Wed Dec 16 14:07:21 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Wed, 16 Dec 2009 22:07:21 +0200
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <C209EE67-D3F8-4A8D-B63C-A5E295719383@apple.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>	<6a8523d60912160339n72e439an10854ba1e37c2a2e@mail.gmail.com>
	<C209EE67-D3F8-4A8D-B63C-A5E295719383@apple.com>
Message-ID: <4B293DF9.1000607@gmail.com>

On 2009-12-16 20:12, Mike Stump wrote:
> On Dec 16, 2009, at 3:39 AM, Daniel Dunbar wrote:
>   
>> Have you considered running this on an LLVM nightly test run?
>>     
>
> Love to see the results; my email was to solicit others into trying the feature out on their favorite code.
>
> Also, I guess I should say, if people have undefined behavior that they would just love to see runtime checks for, maybe to catch portability problems, or to catch security problems or just random bugs in code, I've love to hear the ideas.
>   

Well some of the ideas I have would overlap with what SAFEcode already does.

Ideally it should catch all the undefined behavior that would cause
different behavior when program is compiled with -O0 vs compiled with
-O2. Or in other words, any undefined behavior that could break (the
user's expectations) due to compiler optimizations.
That "idea" is too vague to be useful, so below are some specific ideas,
some already crash at runtime but a better error message
would be very useful.

A general idea first: please allow for individual tests to be turned
on/off, for example I may want to test only for
array overflows, only for shift overflows, etc.
Or if I compile with -fno-strict-aliasing I wouldn't care about aliasing
violations, etc.

1. support something similar to gcc's "-fmudflapth":
  It is useful on occasion when valgrind can't find errors (such as
overrunning a stack allocated buffer). You already do something similar,
however I'd be interested to catch bugs when the buffer (of constant
size) is declared in one function, and the buggy store/load is in
another function.
2. alignment testing
 This is something I haven't found a tool for. Especially important for
sparc, but thats needs a sparc CPU for testing.
It'd be nice if we could catch these bugs by running on x86, and
assuming sparc alignment rules. Even on x86, vectorized variables need
to be aligned, or it crashes.
3. pointer overflows, undefined behavior in userspace
4. aliasing rule violations via casts
 Although LLVM doesn't have TBAA yet, clang could catch some TBAA
errors, when the dynamic type of a casted value doesn't match
5. other aliasing violations
 - restrict qualifier not obeyed (i.e. a noalias pointer indeed aliases
something)
 - two pointers have equal value, yet according to aliasing rules they
never alias (for example overflowing from one struct field to another)
6. pure/const qualifier checks
7. calling convention mismatches
8. noreturn that returns
9. division by zero due to overflow (32-bit division of -2147483648 by -1)
10.  Access to a variable from multiple threads without proper
locking/atomic instructions
11. weak symbols with an initializer, overriden  with another
initializer at link time (optimizer may assume the  initial value it has
seen)
12. use of uninitialized variable
13. calling function using wrong prototype (for example library compiled
with certain flags, function has 5 params, user
compiles with other flags, function has 4 params. At runtime it will
crash/misbehave for C.
Even for C++ its a problem if structures have different
layout/elements). The types' structure should match, including pointed
to types

I had a list with some more ideas, but I can't find that file right now,
if I find it, I'll follow up.

Best regards,
--Edwin

From daniel at zuster.org  Wed Dec 16 14:08:49 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Wed, 16 Dec 2009 12:08:49 -0800
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <4B2936A4.7090802@gmail.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
	<4B28C8C2.5050606@gmail.com>
	<6B6F2033-1BC1-44AA-BF2B-4B7A741DD41B@apple.com>
	<4B2936A4.7090802@gmail.com>
Message-ID: <6a8523d60912161208k4fc1512cicb4df1a1cf305297@mail.gmail.com>

2009/12/16 T?r?k Edwin <edwintorok at gmail.com>:
> On 2009-12-16 20:36, Mike Stump wrote:
>> On Dec 16, 2009, at 3:47 AM, T?r?k Edwin wrote:
>>
>>> This is a very interesting feature!
>>>
>>
>>
>>> However I found no way to skip this error, to look for more errors.
>>>
>>
>> Yeah, limitation of the current codegen. ?Trivially, one could imagine logging interface codegen. ?It could include column and line numbers, filenames and what rule was violated and how (the shift amount was 128 bits). ?I think filing a PR for a logging system would make a nice addition. ?Great for large codebases when build test cycle times are in the 1-3 day range.
>>
>
> Ok. As a short term solution could it generate an int3 though instead of
> an illegal instruction?
>
>>
>>> Also would it be possible to warn about shift exceeding width only if they can change the outcome?
>>>
>>
>> Well, the notion that some undefined behavior is defined and perfectly ok, is an odd notion. ?Rather, think of it this way, the runtime check is trying to tell you that the `portable' version of ROR doesn't work on ppc and that you need to fix your code to be portable. ?After it is fixed, there will be no runtime failure. ?In fact, one of the purposes of the check was to find exactly this type of non-portable code.
>>
>
> For the case where the shift amount is constant, I agree that it is
> undefined, for (uint32_t x=...; x << 32) the compiler can say that x is
> 42 (or some other random value).
>
> However when the shift amount is not constant, the compiler has no
> choice but to implement the shift with CPU instructions (it may or may
> not recognize the ror pattern, currently it doesn't).
> In that case the undefined behavior for the shift becomes an
> implementation defined behavior of the CPU.

This isn't the correct understanding of undefined behavior. The
compiler is perfectly free to optimize all subsequent code in your
program as if the shift value is in the range [0,32), since if it
wasn't the behavior would have be undefined. This has larger
implications than just the result of the shift.

OTOH I agree this is mostly a pedantic point, but overall I agree with
Mike -- the flag should catch undefined behavior. If the programmer
wants to say "oh, yeah, but no compiler will *ever* make me regret
that" then one reasonable way out would be to disable it with a pragma
or attribute.

 - Daniel

> For the CLI_ROR case, the only scenario where the undefined behavior
> might occur (and I don't consider it a bug) is if shift amount == bitwidth,
> in which case it depends on the CPU what happens
> (X86 appears to shift by 0, PPC shifts all bits out and result is 0). In
> either case the end result of the CLI_ROR macro is the same, since a|a
> == a|0.
>
> For higher shift amounts the result may not be the same, but I think for
> shift amount == bitwidth the result is still correct.
>
> Indeed when the rotate amount passes to CLI_ROR is greater than
> bitwidth, that should be fixed, see here:
> https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1778
>
>>
>>> The shift of 32 could be worked around by checking whether b is 0, but that adds another branch.
>>>
>>
>> A branch on a constant is relatively free. ?A smart optimizer, having a ror instruction on the target, would always eliminate the branch as well.
>>
>> Consider what happens when a is constant, and the emulation for shift at compile time doesn't match the runtime behavior of shift, the wrong value is computed. ?Might not happen on a native compiler, but odds of this happening under cross compilation go up.
>
> Yeah the branch for the constant case would be fine, however it would
> mean a penalty for the non-constant shift case.
>
> Best regards,
> --Edwin
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From edwintorok at gmail.com  Wed Dec 16 15:23:47 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Wed, 16 Dec 2009 23:23:47 +0200
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <4B293DF9.1000607@gmail.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>	<6a8523d60912160339n72e439an10854ba1e37c2a2e@mail.gmail.com>
	<C209EE67-D3F8-4A8D-B63C-A5E295719383@apple.com>
	<4B293DF9.1000607@gmail.com>
Message-ID: <4B294FE3.5040709@gmail.com>

On 2009-12-16 22:07, T?r?k Edwin wrote:
> On 2009-12-16 20:12, Mike Stump wrote:
>   
>> On Dec 16, 2009, at 3:39 AM, Daniel Dunbar wrote:
>>   
>>     
>>> Have you considered running this on an LLVM nightly test run?
>>>     
>>>       
>> Love to see the results; my email was to solicit others into trying the feature out on their favorite code.
>>
>> Also, I guess I should say, if people have undefined behavior that they would just love to see runtime checks for, maybe to catch portability problems, or to catch security problems or just random bugs in code, I've love to hear the ideas.
>>   
>>     
>
> Well some of the ideas I have would overlap with what SAFEcode already does.
>
> Ideally it should catch all the undefined behavior that would cause
> different behavior when program is compiled with -O0 vs compiled with
> -O2. Or in other words, any undefined behavior that could break (the
> user's expectations) due to compiler optimizations.
> That "idea" is too vague to be useful, so below are some specific ideas,
> some already crash at runtime but a better error message
> would be very useful.
>
> A general idea first: please allow for individual tests to be turned
> on/off, for example I may want to test only for
> array overflows, only for shift overflows, etc.
> Or if I compile with -fno-strict-aliasing I wouldn't care about aliasing
> violations, etc.
>
> 1. support something similar to gcc's "-fmudflapth":
>   It is useful on occasion when valgrind can't find errors (such as
> overrunning a stack allocated buffer). You already do something similar,
> however I'd be interested to catch bugs when the buffer (of constant
> size) is declared in one function, and the buggy store/load is in
> another function.
> 2. alignment testing
>  This is something I haven't found a tool for. Especially important for
> sparc, but thats needs a sparc CPU for testing.
> It'd be nice if we could catch these bugs by running on x86, and
> assuming sparc alignment rules. Even on x86, vectorized variables need
> to be aligned, or it crashes.
> 3. pointer overflows, undefined behavior in userspace
> 4. aliasing rule violations via casts
>  Although LLVM doesn't have TBAA yet, clang could catch some TBAA
> errors, when the dynamic type of a casted value doesn't match
> 5. other aliasing violations
>  - restrict qualifier not obeyed (i.e. a noalias pointer indeed aliases
> something)
>  - two pointers have equal value, yet according to aliasing rules they
> never alias (for example overflowing from one struct field to another)
> 6. pure/const qualifier checks
> 7. calling convention mismatches
> 8. noreturn that returns
> 9. division by zero due to overflow (32-bit division of -2147483648 by -1)
> 10.  Access to a variable from multiple threads without proper
> locking/atomic instructions
> 11. weak symbols with an initializer, overriden  with another
> initializer at link time (optimizer may assume the  initial value it has
> seen)
> 12. use of uninitialized variable
> 13. calling function using wrong prototype (for example library compiled
> with certain flags, function has 5 params, user
> compiles with other flags, function has 4 params. At runtime it will
> crash/misbehave for C.
> Even for C++ its a problem if structures have different
> layout/elements). The types' structure should match, including pointed
> to types
>
> I had a list with some more ideas, but I can't find that file right now,
> if I find it, I'll follow up.
>   

14. malloc of possibly wrapped value: x = malloc(a+b); memset(x, 0, a);
memset(x+a, 0, b); // if a+b overflowed, then a+b < a, or a+b < b
15. incorrect buffer limit checks:
     if (tainted_signed_value <= (long) some_limit)
a[tainted_signed_value]; //<--- code should check for negative values as
well
     same situation if comparison becomes signed due to integer
promotion rules.
16. a warning (not undef behavior, but could be a mistake) for integer
promotion of signed value to unsigned when target variable is signed:
int x=-2; unsigned y=1; long a0 = x + y; value of a0 will be 4294967295,
though a0 is a signed variable!


Best regards,
--Edwin

From mrs at apple.com  Wed Dec 16 16:51:47 2009
From: mrs at apple.com (Mike Stump)
Date: Wed, 16 Dec 2009 14:51:47 -0800
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <4B294FE3.5040709@gmail.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
	<6a8523d60912160339n72e439an10854ba1e37c2a2e@mail.gmail.com>
	<C209EE67-D3F8-4A8D-B63C-A5E295719383@apple.com>
	<4B293DF9.1000607@gmail.com> <4B294FE3.5040709@gmail.com>
Message-ID: <2754A0FD-DB22-4DA8-9D4B-ADBCBA2F4E57@apple.com>

On Dec 16, 2009, at 1:23 PM, T?r?k Edwin wrote:
> 15. incorrect buffer limit checks:
>     if (tainted_signed_value <= (long) some_limit)
> a[tainted_signed_value]; //<--- code should check for negative values as
> well

Ah, this one we already have check for, in the case where the memory that backs a is known to the optimizer (after llvm implements more of the object_size builtin).

From mrs at apple.com  Wed Dec 16 16:58:35 2009
From: mrs at apple.com (Mike Stump)
Date: Wed, 16 Dec 2009 14:58:35 -0800
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <4B2936A4.7090802@gmail.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
	<4B28C8C2.5050606@gmail.com>
	<6B6F2033-1BC1-44AA-BF2B-4B7A741DD41B@apple.com>
	<4B2936A4.7090802@gmail.com>
Message-ID: <F647C3A9-EEFD-4649-B92A-9B2AA1534405@apple.com>

On Dec 16, 2009, at 11:36 AM, T?r?k Edwin wrote:
> Ok. As a short term solution could it generate an int3 though instead of an illegal instruction?

Which llvm intrinsic is that?

> Yeah the branch for the constant case would be fine, however it would mean a penalty for the non-constant shift case.

As I said, for an optimizing compiler, it could omit the penalty, if it cared.

From redbully at cc.hs-owl.de  Wed Dec 16 18:21:29 2009
From: redbully at cc.hs-owl.de (Jan 'RedBully' Seiffert)
Date: Thu, 17 Dec 2009 01:21:29 +0100
Subject: [cfe-dev] -fcatch-undefined-behavior testing
Message-ID: <4B297989.1070602@cc.hs-owl.de>

1. Nice!

2.
 ....
 804bc26:       0f 0b                   ud2a
 ....
 804bd1f:       83 f8 02                cmp    $0x2,%eax
 804bd22:       0f 87 63 01 00 00       ja     804be8b <main+0xecb>
 804bd28:       83 f8 03                cmp    $0x3,%eax
 804bd2b:       0f 87 f5 fe ff ff       ja     804bc26 <main+0xc66>
 ....

Thats what i get for defensiv coding? :(
(after the first couple instances of stuff like this i stopped grepping for ud2a
and it's addresses)

3.
Can clang/llvm use into (the only conditional trap on x86) for such things?
Or int3? Should give a:
SIGTRAP        5        Core    Trace/breakpoint trap
Or drop you into the debugger.

Greetings
	Jan

-- 
The Theorem Theorem: If If, Then Then.

From clattner at apple.com  Wed Dec 16 23:45:01 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 16 Dec 2009 21:45:01 -0800
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <4B297989.1070602@cc.hs-owl.de>
References: <4B297989.1070602@cc.hs-owl.de>
Message-ID: <3FF18545-F336-4C64-98ED-986B0231F734@apple.com>


On Dec 16, 2009, at 4:21 PM, Jan 'RedBully' Seiffert wrote:

> 1. Nice!
> 
> 2.
> ....
> 804bc26:       0f 0b                   ud2a
> ....
> 804bd1f:       83 f8 02                cmp    $0x2,%eax
> 804bd22:       0f 87 63 01 00 00       ja     804be8b <main+0xecb>
> 804bd28:       83 f8 03                cmp    $0x3,%eax
> 804bd2b:       0f 87 f5 fe ff ff       ja     804bc26 <main+0xc66>
> ....
> 
> Thats what i get for defensiv coding? :(
> (after the first couple instances of stuff like this i stopped grepping for ud2a
> and it's addresses)
> 
> 3.
> Can clang/llvm use into (the only conditional trap on x86) for such things?
> Or int3? Should give a:
> SIGTRAP        5        Core    Trace/breakpoint trap
> Or drop you into the debugger.

Yes, it would be nice for the code generator to turn "branch + builtin trap" into "into" when possible.

-Chris

From edwintorok at gmail.com  Thu Dec 17 01:52:23 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Thu, 17 Dec 2009 09:52:23 +0200
Subject: [cfe-dev] -fcatch-undefined-behavior testing
In-Reply-To: <F647C3A9-EEFD-4649-B92A-9B2AA1534405@apple.com>
References: <35C3A803-0B10-4F86-9B74-D5CC6917D887@apple.com>
	<4B28C8C2.5050606@gmail.com>
	<6B6F2033-1BC1-44AA-BF2B-4B7A741DD41B@apple.com>
	<4B2936A4.7090802@gmail.com>
	<F647C3A9-EEFD-4649-B92A-9B2AA1534405@apple.com>
Message-ID: <4B29E337.70002@gmail.com>

On 2009-12-17 00:58, Mike Stump wrote:
> On Dec 16, 2009, at 11:36 AM, T?r?k Edwin wrote:
>   
>> Ok. As a short term solution could it generate an int3 though instead of an illegal instruction?
>>     
>
> Which llvm intrinsic is that?
>   

No target independent intrinsic, I only know of a target-dependent way
for x86:
tail call void asm sideeffect "int3", "~{dirflag},~{fpsr},~{flags}"()
nounwind

>   
>> Yeah the branch for the constant case would be fine, however it would mean a penalty for the non-constant shift case.
>>     
>
> As I said, for an optimizing compiler, it could omit the penalty, if it cared.


Ok.

Best regards,
--Edwin

From abramobagnara at tin.it  Thu Dec 17 06:05:33 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Thu, 17 Dec 2009 13:05:33 +0100
Subject: [cfe-dev] Source rewrite
Message-ID: <4B2A1E8D.3040609@tin.it>

In an application that uses clang libraries we need to transform some
specially written comments in C construct.

e.g:
int p() {
	int a = 3;
	/* #instrument(a)# */
}

should be parsed as
int p() {
	int a = 3;
	instrument(a);
}

I've added a CommentHandler to Preprocessor to catch comments and I
thought to use Rewriter class to manipulate the input buffer inserting
after the comment the text to be parsed, but then I've realized that
Rewriter class is not designed to rewrite lexer input buffers, but to
build a separate object where original text and changes live together.

Now I'm a bit confused: what's the proper way to cope with the need
described above?


From snaroff at apple.com  Thu Dec 17 07:23:19 2009
From: snaroff at apple.com (steve naroff)
Date: Thu, 17 Dec 2009 08:23:19 -0500
Subject: [cfe-dev] Source rewrite
In-Reply-To: <4B2A1E8D.3040609@tin.it>
References: <4B2A1E8D.3040609@tin.it>
Message-ID: <97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>


On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:

> In an application that uses clang libraries we need to transform some
> specially written comments in C construct.
>
> e.g:
> int p() {
> 	int a = 3;
> 	/* #instrument(a)# */
> }
>
> should be parsed as
> int p() {
> 	int a = 3;
> 	instrument(a);
> }
>
> I've added a CommentHandler to Preprocessor to catch comments and I
> thought to use Rewriter class to manipulate the input buffer inserting
> after the comment the text to be parsed, but then I've realized that
> Rewriter class is not designed to rewrite lexer input buffers, but to
> build a separate object where original text and changes live together.
>
> Now I'm a bit confused: what's the proper way to cope with the need
> described above?
>

Hi Abramo,

The ASTContext class has a 'Comments' member that contains all the  
SourceRanges's for all comments in the source file.

This assumes you've told the preprocessor to keep comments.

This might not be the only/proper way, however I thought you should be  
aware of this...

snaroff

> _______________________________________________
> 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 Dec 17 09:57:44 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 17 Dec 2009 07:57:44 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
Message-ID: <CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>


On Dec 17, 2009, at 5:23 AM, steve naroff wrote:

> 
> On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:
> 
>> In an application that uses clang libraries we need to transform some
>> specially written comments in C construct.
>> 
>> e.g:
>> int p() {
>> 	int a = 3;
>> 	/* #instrument(a)# */
>> }
>> 
>> should be parsed as
>> int p() {
>> 	int a = 3;
>> 	instrument(a);
>> }
>> 
>> I've added a CommentHandler to Preprocessor to catch comments and I
>> thought to use Rewriter class to manipulate the input buffer inserting
>> after the comment the text to be parsed, but then I've realized that
>> Rewriter class is not designed to rewrite lexer input buffers, but to
>> build a separate object where original text and changes live together.
>> 
>> Now I'm a bit confused: what's the proper way to cope with the need
>> described above?
>> 
> 
> Hi Abramo,
> 
> The ASTContext class has a 'Comments' member that contains all the  
> SourceRanges's for all comments in the source file.
> 
> This assumes you've told the preprocessor to keep comments.

You actually don't have to tell the preprocessor to keep comments; it keeps the source ranges for the comments regardless, and you can go back to the source to get the content of the comments.

	- Doug

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

From abramobagnara at tin.it  Thu Dec 17 11:13:01 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Thu, 17 Dec 2009 18:13:01 +0100
Subject: [cfe-dev] Source rewrite
In-Reply-To: <CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
Message-ID: <4B2A669D.8060406@tin.it>

Il 17/12/2009 16:57, Douglas Gregor ha scritto:
> 
> On Dec 17, 2009, at 5:23 AM, steve naroff wrote:
> 
>>
>> On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:
>>
>>> In an application that uses clang libraries we need to transform some
>>> specially written comments in C construct.
>>>
>>> e.g:
>>> int p() {
>>> int a = 3;
>>> /* #instrument(a)# */
>>> }
>>>
>>> should be parsed as
>>> int p() {
>>> int a = 3;
>>> instrument(a);
>>> }
>>>
>>> I've added a CommentHandler to Preprocessor to catch comments and I
>>> thought to use Rewriter class to manipulate the input buffer inserting
>>> after the comment the text to be parsed, but then I've realized that
>>> Rewriter class is not designed to rewrite lexer input buffers, but to
>>> build a separate object where original text and changes live together.
>>>
>>> Now I'm a bit confused: what's the proper way to cope with the need
>>> described above?
>>>
>>
>> Hi Abramo,
>>
>> The ASTContext class has a 'Comments' member that contains all the  
>> SourceRanges's for all comments in the source file.
>>
>> This assumes you've told the preprocessor to keep comments.
> 
> You actually don't have to tell the preprocessor to keep comments; it
> keeps the source ranges for the comments regardless, and you can go back
> to the source to get the content of the comments.

I think to have explained badly what we need: I've no problems to get
the comment content, my problem is to translate, during the parsing, the
comment content in another text to be lexed/parsed instead of (or just
after) the comment.

As I write above, what I need is that the AST built from:

int p() {
  int a = 3;
  /* #instrument(a)# */
}

is as if the source read was:

int p() {
  int a = 3;
  instrument(a);
}



From dgregor at apple.com  Thu Dec 17 11:23:47 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 17 Dec 2009 09:23:47 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <4B2A669D.8060406@tin.it>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
Message-ID: <6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>


On Dec 17, 2009, at 9:13 AM, Abramo Bagnara wrote:

> Il 17/12/2009 16:57, Douglas Gregor ha scritto:
>>
>> On Dec 17, 2009, at 5:23 AM, steve naroff wrote:
>>
>>>
>>> On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:
>>>
>>>> In an application that uses clang libraries we need to transform  
>>>> some
>>>> specially written comments in C construct.
>>>>
>>>> e.g:
>>>> int p() {
>>>> int a = 3;
>>>> /* #instrument(a)# */
>>>> }
>>>>
>>>> should be parsed as
>>>> int p() {
>>>> int a = 3;
>>>> instrument(a);
>>>> }
>>>>
>>>> I've added a CommentHandler to Preprocessor to catch comments and I
>>>> thought to use Rewriter class to manipulate the input buffer  
>>>> inserting
>>>> after the comment the text to be parsed, but then I've realized  
>>>> that
>>>> Rewriter class is not designed to rewrite lexer input buffers,  
>>>> but to
>>>> build a separate object where original text and changes live  
>>>> together.
>>>>
>>>> Now I'm a bit confused: what's the proper way to cope with the need
>>>> described above?
>>>>
>>>
>>> Hi Abramo,
>>>
>>> The ASTContext class has a 'Comments' member that contains all the
>>> SourceRanges's for all comments in the source file.
>>>
>>> This assumes you've told the preprocessor to keep comments.
>>
>> You actually don't have to tell the preprocessor to keep comments; it
>> keeps the source ranges for the comments regardless, and you can go  
>> back
>> to the source to get the content of the comments.
>
> I think to have explained badly what we need: I've no problems to get
> the comment content, my problem is to translate, during the parsing,  
> the
> comment content in another text to be lexed/parsed instead of (or just
> after) the comment.
>
> As I write above, what I need is that the AST built from:
>
> int p() {
>  int a = 3;
>  /* #instrument(a)# */
> }
>
> is as if the source read was:
>
> int p() {
>  int a = 3;
>  instrument(a);
> }


Oh, interesting. You'll probably need to each the preprocessor how to  
parse inside these comments. One option might be to treat such  
comments similarly to macro expansion, so that processing the comment

   /* #instrument(a)# */

consumes the comment and then pushes a new lexer that will point into  
a buffer containing

   instrument(a)

just like processing

   FOO

where there is a macro definition

   #define FOO instrument(a)

will create a new lexer pointing into a buffer containing

   instrument(a)

	- Doug

From fjahanian at apple.com  Thu Dec 17 11:32:20 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Thu, 17 Dec 2009 09:32:20 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
Message-ID: <33000EFA-F3BC-4771-9F9A-77E8EB91E7F2@apple.com>


On Dec 17, 2009, at 9:23 AM, Douglas Gregor wrote:

>
> On Dec 17, 2009, at 9:13 AM, Abramo Bagnara wrote:
>
>> Il 17/12/2009 16:57, Douglas Gregor ha scritto:
>>>
>>> On Dec 17, 2009, at 5:23 AM, steve naroff wrote:
>>>
>>>>
>>>> On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:
>>>>
>>>>> In an application that uses clang libraries we need to transform
>>>>> some
>>>>> specially written comments in C construct.
>>>>>
>>>>> e.g:
>>>>> int p() {
>>>>> int a = 3;
>>>>> /* #instrument(a)# */
>>>>> }
>>>>>
>>>>> should be parsed as
>>>>> int p() {
>>>>> int a = 3;
>>>>> instrument(a);
>>>>> }
>>>>>
>>>>> I've added a CommentHandler to Preprocessor to catch comments  
>>>>> and I
>>>>> thought to use Rewriter class to manipulate the input buffer
>>>>> inserting
>>>>> after the comment the text to be parsed, but then I've realized
>>>>> that
>>>>> Rewriter class is not designed to rewrite lexer input buffers,
>>>>> but to
>>>>> build a separate object where original text and changes live
>>>>> together.
>>>>>
>>>>> Now I'm a bit confused: what's the proper way to cope with the  
>>>>> need
>>>>> described above?
>>>>>
>>>>
>>>> Hi Abramo,
>>>>
>>>> The ASTContext class has a 'Comments' member that contains all the
>>>> SourceRanges's for all comments in the source file.
>>>>
>>>> This assumes you've told the preprocessor to keep comments.
>>>
>>> You actually don't have to tell the preprocessor to keep comments;  
>>> it
>>> keeps the source ranges for the comments regardless, and you can go
>>> back
>>> to the source to get the content of the comments.
>>
>> I think to have explained badly what we need: I've no problems to get
>> the comment content, my problem is to translate, during the parsing,
>> the
>> comment content in another text to be lexed/parsed instead of (or  
>> just
>> after) the comment.
>>
>> As I write above, what I need is that the AST built from:
>>
>> int p() {
>> int a = 3;
>> /* #instrument(a)# */
>> }
>>
>> is as if the source read was:
>>
>> int p() {
>> int a = 3;
>> instrument(a);
>> }
>
>
> Oh, interesting. You'll probably need to each the preprocessor how to
> parse inside these comments. One option might be to treat such
> comments similarly to macro expansion, so that processing the comment
>
>   /* #instrument(a)# */
>
> consumes the comment and then pushes a new lexer that will point into
> a buffer containing
>
>   instrument(a)
>
> just like processing
>
>   FOO
>
> where there is a macro definition
>
>   #define FOO instrument(a)
>
> will create a new lexer pointing into a buffer containing
>
>   instrument(a)

Somehow, all semantics checks need be performed and an 'invisible' AST  
generated and passed on so rewriter can do
the rewrite.

- Fariborz

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


From abramobagnara at tin.it  Thu Dec 17 11:37:12 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Thu, 17 Dec 2009 18:37:12 +0100
Subject: [cfe-dev] Source rewrite
In-Reply-To: <6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
Message-ID: <4B2A6C48.1080208@tin.it>

Il 17/12/2009 18:23, Douglas Gregor ha scritto:
> 
> On Dec 17, 2009, at 9:13 AM, Abramo Bagnara wrote:
> 
>> Il 17/12/2009 16:57, Douglas Gregor ha scritto:
>>>
>>> On Dec 17, 2009, at 5:23 AM, steve naroff wrote:
>>>
>>>>
>>>> On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:
>>>>
>>>>> In an application that uses clang libraries we need to transform some
>>>>> specially written comments in C construct.
>>>>>
>>>>> e.g:
>>>>> int p() {
>>>>> int a = 3;
>>>>> /* #instrument(a)# */
>>>>> }
>>>>>
>>>>> should be parsed as
>>>>> int p() {
>>>>> int a = 3;
>>>>> instrument(a);
>>>>> }
>>>>>
>>>>> I've added a CommentHandler to Preprocessor to catch comments and I
>>>>> thought to use Rewriter class to manipulate the input buffer inserting
>>>>> after the comment the text to be parsed, but then I've realized that
>>>>> Rewriter class is not designed to rewrite lexer input buffers, but to
>>>>> build a separate object where original text and changes live together.
>>>>>
>>>>> Now I'm a bit confused: what's the proper way to cope with the need
>>>>> described above?
>>>>>
>>>>
>>>> Hi Abramo,
>>>>
>>>> The ASTContext class has a 'Comments' member that contains all the
>>>> SourceRanges's for all comments in the source file.
>>>>
>>>> This assumes you've told the preprocessor to keep comments.
>>>
>>> You actually don't have to tell the preprocessor to keep comments; it
>>> keeps the source ranges for the comments regardless, and you can go back
>>> to the source to get the content of the comments.
>>
>> I think to have explained badly what we need: I've no problems to get
>> the comment content, my problem is to translate, during the parsing, the
>> comment content in another text to be lexed/parsed instead of (or just
>> after) the comment.
>>
>> As I write above, what I need is that the AST built from:
>>
>> int p() {
>>  int a = 3;
>>  /* #instrument(a)# */
>> }
>>
>> is as if the source read was:
>>
>> int p() {
>>  int a = 3;
>>  instrument(a);
>> }
> 
> 
> Oh, interesting. You'll probably need to each the preprocessor how to
> parse inside these comments. One option might be to treat such comments
> similarly to macro expansion, so that processing the comment
> 
>   /* #instrument(a)# */
> 
> consumes the comment and then pushes a new lexer that will point into a
> buffer containing
> 
>   instrument(a)
> 
> just like processing
> 
>   FOO
> 
> where there is a macro definition
> 
>   #define FOO instrument(a)
> 
> will create a new lexer pointing into a buffer containing
> 
>   instrument(a)

Yes, this is what jumped in my mind after sending the original message.

Reading your message I now guess that nobody has attempted that
before... I think that I'll try this approach.

Thanks indeed for your help.

From dgregor at apple.com  Thu Dec 17 11:37:39 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 17 Dec 2009 09:37:39 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <33000EFA-F3BC-4771-9F9A-77E8EB91E7F2@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<33000EFA-F3BC-4771-9F9A-77E8EB91E7F2@apple.com>
Message-ID: <C15D7B57-F5DA-45FA-A9BF-A6A3AD8B5226@apple.com>


On Dec 17, 2009, at 9:32 AM, Fariborz Jahanian wrote:

>
> On Dec 17, 2009, at 9:23 AM, Douglas Gregor wrote:
>
>>
>> On Dec 17, 2009, at 9:13 AM, Abramo Bagnara wrote:
>>
>>> Il 17/12/2009 16:57, Douglas Gregor ha scritto:
>>>>
>>>> On Dec 17, 2009, at 5:23 AM, steve naroff wrote:
>>>>
>>>>>
>>>>> On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:
>>>>>
>>>>>> In an application that uses clang libraries we need to transform
>>>>>> some
>>>>>> specially written comments in C construct.
>>>>>>
>>>>>> e.g:
>>>>>> int p() {
>>>>>> int a = 3;
>>>>>> /* #instrument(a)# */
>>>>>> }
>>>>>>
>>>>>> should be parsed as
>>>>>> int p() {
>>>>>> int a = 3;
>>>>>> instrument(a);
>>>>>> }
>>>>>>
>>>>>> I've added a CommentHandler to Preprocessor to catch comments  
>>>>>> and I
>>>>>> thought to use Rewriter class to manipulate the input buffer
>>>>>> inserting
>>>>>> after the comment the text to be parsed, but then I've realized
>>>>>> that
>>>>>> Rewriter class is not designed to rewrite lexer input buffers,
>>>>>> but to
>>>>>> build a separate object where original text and changes live
>>>>>> together.
>>>>>>
>>>>>> Now I'm a bit confused: what's the proper way to cope with the  
>>>>>> need
>>>>>> described above?
>>>>>>
>>>>>
>>>>> Hi Abramo,
>>>>>
>>>>> The ASTContext class has a 'Comments' member that contains all the
>>>>> SourceRanges's for all comments in the source file.
>>>>>
>>>>> This assumes you've told the preprocessor to keep comments.
>>>>
>>>> You actually don't have to tell the preprocessor to keep  
>>>> comments; it
>>>> keeps the source ranges for the comments regardless, and you can go
>>>> back
>>>> to the source to get the content of the comments.
>>>
>>> I think to have explained badly what we need: I've no problems to  
>>> get
>>> the comment content, my problem is to translate, during the parsing,
>>> the
>>> comment content in another text to be lexed/parsed instead of (or  
>>> just
>>> after) the comment.
>>>
>>> As I write above, what I need is that the AST built from:
>>>
>>> int p() {
>>> int a = 3;
>>> /* #instrument(a)# */
>>> }
>>>
>>> is as if the source read was:
>>>
>>> int p() {
>>> int a = 3;
>>> instrument(a);
>>> }
>>
>>
>> Oh, interesting. You'll probably need to each the preprocessor how to
>> parse inside these comments. One option might be to treat such
>> comments similarly to macro expansion, so that processing the comment
>>
>>  /* #instrument(a)# */
>>
>> consumes the comment and then pushes a new lexer that will point into
>> a buffer containing
>>
>>  instrument(a)
>>
>> just like processing
>>
>>  FOO
>>
>> where there is a macro definition
>>
>>  #define FOO instrument(a)
>>
>> will create a new lexer pointing into a buffer containing
>>
>>  instrument(a)
>
> Somehow, all semantics checks need be performed and an 'invisible'  
> AST generated and passed on so rewriter can do
> the rewrite.

Right. What I've described will do the first part---allow parsing of  
the code within the comments to produce an AST---and the rewrite can  
handle the second part, rewriting the comment to something else (e.g.,  
the text parsed within the comment).

	- Doug

> - Fariborz
>
>>
>>
>> 	- Doug
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From abramobagnara at tin.it  Thu Dec 17 11:44:24 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Thu, 17 Dec 2009 18:44:24 +0100
Subject: [cfe-dev] Source rewrite
In-Reply-To: <33000EFA-F3BC-4771-9F9A-77E8EB91E7F2@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<33000EFA-F3BC-4771-9F9A-77E8EB91E7F2@apple.com>
Message-ID: <4B2A6DF8.8070302@tin.it>

Il 17/12/2009 18:32, Fariborz Jahanian ha scritto:
> 
> On Dec 17, 2009, at 9:23 AM, Douglas Gregor wrote:
> 
>>
>> On Dec 17, 2009, at 9:13 AM, Abramo Bagnara wrote:
>>
>>> Il 17/12/2009 16:57, Douglas Gregor ha scritto:
>>>>
>>>> On Dec 17, 2009, at 5:23 AM, steve naroff wrote:
>>>>
>>>>>
>>>>> On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:
>>>>>
>>>>>> In an application that uses clang libraries we need to transform
>>>>>> some
>>>>>> specially written comments in C construct.
>>>>>>
>>>>>> e.g:
>>>>>> int p() {
>>>>>> int a = 3;
>>>>>> /* #instrument(a)# */
>>>>>> }
>>>>>>
>>>>>> should be parsed as
>>>>>> int p() {
>>>>>> int a = 3;
>>>>>> instrument(a);
>>>>>> }
>>>>>>
>>>>>> I've added a CommentHandler to Preprocessor to catch comments and I
>>>>>> thought to use Rewriter class to manipulate the input buffer
>>>>>> inserting
>>>>>> after the comment the text to be parsed, but then I've realized
>>>>>> that
>>>>>> Rewriter class is not designed to rewrite lexer input buffers,
>>>>>> but to
>>>>>> build a separate object where original text and changes live
>>>>>> together.
>>>>>>
>>>>>> Now I'm a bit confused: what's the proper way to cope with the need
>>>>>> described above?
>>>>>>
>>>>>
>>>>> Hi Abramo,
>>>>>
>>>>> The ASTContext class has a 'Comments' member that contains all the
>>>>> SourceRanges's for all comments in the source file.
>>>>>
>>>>> This assumes you've told the preprocessor to keep comments.
>>>>
>>>> You actually don't have to tell the preprocessor to keep comments; it
>>>> keeps the source ranges for the comments regardless, and you can go
>>>> back
>>>> to the source to get the content of the comments.
>>>
>>> I think to have explained badly what we need: I've no problems to get
>>> the comment content, my problem is to translate, during the parsing,
>>> the
>>> comment content in another text to be lexed/parsed instead of (or just
>>> after) the comment.
>>>
>>> As I write above, what I need is that the AST built from:
>>>
>>> int p() {
>>> int a = 3;
>>> /* #instrument(a)# */
>>> }
>>>
>>> is as if the source read was:
>>>
>>> int p() {
>>> int a = 3;
>>> instrument(a);
>>> }
>>
>>
>> Oh, interesting. You'll probably need to each the preprocessor how to
>> parse inside these comments. One option might be to treat such
>> comments similarly to macro expansion, so that processing the comment
>>
>>   /* #instrument(a)# */
>>
>> consumes the comment and then pushes a new lexer that will point into
>> a buffer containing
>>
>>   instrument(a)
>>
>> just like processing
>>
>>   FOO
>>
>> where there is a macro definition
>>
>>   #define FOO instrument(a)
>>
>> will create a new lexer pointing into a buffer containing
>>
>>   instrument(a)
> 
> Somehow, all semantics checks need be performed and an 'invisible' AST
> generated and passed on so rewriter can do
> the rewrite.

I believe to not understand what you mean... I think that the rewriter
is not involved in any way.

From fjahanian at apple.com  Thu Dec 17 11:49:04 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Thu, 17 Dec 2009 09:49:04 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <4B2A6DF8.8070302@tin.it>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<33000EFA-F3BC-4771-9F9A-77E8EB91E7F2@apple.com>
	<4B2A6DF8.8070302@tin.it>
Message-ID: <A284EB71-6360-48A7-A939-D2560DC68AE9@apple.com>


On Dec 17, 2009, at 9:44 AM, Abramo Bagnara wrote:

> Il 17/12/2009 18:32, Fariborz Jahanian ha scritto:
>>
>> On Dec 17, 2009, at 9:23 AM, Douglas Gregor wrote:
>>
>>>
>>> On Dec 17, 2009, at 9:13 AM, Abramo Bagnara wrote:
>>>
>>>> Il 17/12/2009 16:57, Douglas Gregor ha scritto:
>>>>>
>>>>> On Dec 17, 2009, at 5:23 AM, steve naroff wrote:
>>>>>
>>>>>>
>>>>>> On Dec 17, 2009, at 7:05 AM, Abramo Bagnara wrote:
>>>>>>
>>>>>>> In an application that uses clang libraries we need to transform
>>>>>>> some
>>>>>>> specially written comments in C construct.
>>>>>>>
>>>>>>> e.g:
>>>>>>> int p() {
>>>>>>> int a = 3;
>>>>>>> /* #instrument(a)# */
>>>>>>> }
>>>>>>>
>>>>>>> should be parsed as
>>>>>>> int p() {
>>>>>>> int a = 3;
>>>>>>> instrument(a);
>>>>>>> }
>>>>>>>
>>>>>>> I've added a CommentHandler to Preprocessor to catch comments  
>>>>>>> and I
>>>>>>> thought to use Rewriter class to manipulate the input buffer
>>>>>>> inserting
>>>>>>> after the comment the text to be parsed, but then I've realized
>>>>>>> that
>>>>>>> Rewriter class is not designed to rewrite lexer input buffers,
>>>>>>> but to
>>>>>>> build a separate object where original text and changes live
>>>>>>> together.
>>>>>>>
>>>>>>> Now I'm a bit confused: what's the proper way to cope with the  
>>>>>>> need
>>>>>>> described above?
>>>>>>>
>>>>>>
>>>>>> Hi Abramo,
>>>>>>
>>>>>> The ASTContext class has a 'Comments' member that contains all  
>>>>>> the
>>>>>> SourceRanges's for all comments in the source file.
>>>>>>
>>>>>> This assumes you've told the preprocessor to keep comments.
>>>>>
>>>>> You actually don't have to tell the preprocessor to keep  
>>>>> comments; it
>>>>> keeps the source ranges for the comments regardless, and you can  
>>>>> go
>>>>> back
>>>>> to the source to get the content of the comments.
>>>>
>>>> I think to have explained badly what we need: I've no problems to  
>>>> get
>>>> the comment content, my problem is to translate, during the  
>>>> parsing,
>>>> the
>>>> comment content in another text to be lexed/parsed instead of (or  
>>>> just
>>>> after) the comment.
>>>>
>>>> As I write above, what I need is that the AST built from:
>>>>
>>>> int p() {
>>>> int a = 3;
>>>> /* #instrument(a)# */
>>>> }
>>>>
>> Somehow, all semantics checks need be performed and an 'invisible'  
>> AST
>> generated and passed on so rewriter can do
>> the rewrite.
>
> I believe to not understand what you mean... I think that the rewriter
> is not involved in any way.

Don't you want to replace the comment to instrument(a) in the  
rewritten source? If you just want to build ASTs then
you do not need the rewriter.

- Fariborz


From john.thompson.jtsoftware at gmail.com  Thu Dec 17 13:48:23 2009
From: john.thompson.jtsoftware at gmail.com (John Thompson)
Date: Thu, 17 Dec 2009 11:48:23 -0800
Subject: [cfe-dev] Compile errors on Win32
Message-ID: <aad8390912171148k441f160dufc22b18e07b39cf2@mail.gmail.com>

This seems to work:

Index: include/llvm/ADT/SmallVector.h
===================================================================
--- include/llvm/ADT/SmallVector.h (revision 91610)
+++ include/llvm/ADT/SmallVector.h (working copy)
@@ -495,15 +495,15 @@

     // Copy over the elements that we're about to overwrite.
     T *OldEnd = this->end();
-    setEnd(this->end() + NumToInsert);
+    this->setEnd(this->end() + NumToInsert);
     size_t NumOverwritten = OldEnd-I;
-    uninitialized_copy(I, OldEnd, this->end()-NumOverwritten);
+    this->uninitialized_copy(I, OldEnd, this->end()-NumOverwritten);

     // Replace the overwritten part.
     std::copy(From, From+NumOverwritten, I);

     // Insert the non-overwritten middle part.
-    uninitialized_copy(From+NumOverwritten, To, OldEnd);
+    this->uninitialized_copy(From+NumOverwritten, To, OldEnd);
     return I;
   }

Can somebody fix it and get the win32 build bot going again?

-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/20091217/2c3eec4f/attachment.html 

From snaroff at apple.com  Thu Dec 17 13:52:13 2009
From: snaroff at apple.com (steve naroff)
Date: Thu, 17 Dec 2009 14:52:13 -0500
Subject: [cfe-dev] Compile errors on Win32
In-Reply-To: <aad8390912171148k441f160dufc22b18e07b39cf2@mail.gmail.com>
References: <aad8390912171148k441f160dufc22b18e07b39cf2@mail.gmail.com>
Message-ID: <C17FC1BE-6346-47C9-B47D-8C5148E5EFCA@apple.com>

I just made the exact change and it seems to work.

When I finish building/testing, I will commit.

Thanks,

snaroff

On Dec 17, 2009, at 2:48 PM, John Thompson wrote:

> This seems to work:
>
> Index: include/llvm/ADT/SmallVector.h
> ===================================================================
> --- include/llvm/ADT/SmallVector.h (revision 91610)
> +++ include/llvm/ADT/SmallVector.h (working copy)
> @@ -495,15 +495,15 @@
>
>      // Copy over the elements that we're about to overwrite.
>      T *OldEnd = this->end();
> -    setEnd(this->end() + NumToInsert);
> +    this->setEnd(this->end() + NumToInsert);
>      size_t NumOverwritten = OldEnd-I;
> -    uninitialized_copy(I, OldEnd, this->end()-NumOverwritten);
> +    this->uninitialized_copy(I, OldEnd, this->end()-NumOverwritten);
>
>      // Replace the overwritten part.
>      std::copy(From, From+NumOverwritten, I);
>
>      // Insert the non-overwritten middle part.
> -    uninitialized_copy(From+NumOverwritten, To, OldEnd);
> +    this->uninitialized_copy(From+NumOverwritten, To, OldEnd);
>      return I;
>    }
>
> Can somebody fix it and get the win32 build bot going again?
>
> -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/20091217/35d70dfc/attachment.html 

From filcab at gmail.com  Thu Dec 17 16:16:42 2009
From: filcab at gmail.com (Filipe Cabecinhas)
Date: Thu, 17 Dec 2009 22:16:42 +0000
Subject: [cfe-dev] Invalid noreturn
Message-ID: <4B2AADCA.5000901@gmail.com>

Hi.

I was trying to compile git with clang but it yielded the "function 
declared 'noreturn' should not return" error. Here is a small test case:

[filcab at Farnsworth ~] $ cat a.c
#include <stdio.h>
#include <stdlib.h>

#define NORETURN __attribute__((__noreturn__))
extern void a(void);

static NORETURN void die_builtin(int err)
{
         exit(128);
}

static NORETURN void (*die_routine)(int i) = die_builtin;

extern NORETURN void die(int err);
void die (int err)
{
   die_routine(err);
   a();
}


extern NORETURN void aaa(int err);
void aaa(int err)
{
   exit(1);
   a();
}

[filcab at Farnsworth ~] $ clang -c a.c
a.c:20:1: warning: function declared 'noreturn' should not return
       [-Winvalid-noreturn]
}
^
1 diagnostic generated.
[filcab at Farnsworth ~] $


Is this supposed to be like this? Or is it a bug? If I call a noreturn 
function pointer, I get the warning. If I call exit(), I don't.
I was expecting both to have the same behaviour.

The code where I saw this had a die() function which received a va_list. 
After calling this die() function, they "called" the macro va_close() 
and this triggered the warning.

Regards,

   F

From cdavis at mymail.mines.edu  Thu Dec 17 16:35:45 2009
From: cdavis at mymail.mines.edu (Charles Davis)
Date: Thu, 17 Dec 2009 15:35:45 -0700
Subject: [cfe-dev] Invalid noreturn
In-Reply-To: <4B2AADCA.5000901@gmail.com>
References: <4B2AADCA.5000901@gmail.com>
Message-ID: <4B2AB241.6010603@mymail.mines.edu>

Filipe Cabecinhas wrote:
> Hi.
> 
> I was trying to compile git with clang but it yielded the "function 
> declared 'noreturn' should not return" error. Here is a small test case:
> 
> [filcab at Farnsworth ~] $ cat a.c
> #include <stdio.h>
> #include <stdlib.h>
> 
> #define NORETURN __attribute__((__noreturn__))
> extern void a(void);
> 
> static NORETURN void die_builtin(int err)
> {
>          exit(128);
> }
> 
> static NORETURN void (*die_routine)(int i) = die_builtin;
> 
> extern NORETURN void die(int err);
> void die (int err)
> {
>    die_routine(err);
>    a();
> }
> 
> 
> extern NORETURN void aaa(int err);
> void aaa(int err)
> {
>    exit(1);
>    a();
> }
> 
> [filcab at Farnsworth ~] $ clang -c a.c
> a.c:20:1: warning: function declared 'noreturn' should not return
>        [-Winvalid-noreturn]
> }
> ^
> 1 diagnostic generated.
> [filcab at Farnsworth ~] $
> 
> 
> Is this supposed to be like this? Or is it a bug? If I call a noreturn 
> function pointer, I get the warning. If I call exit(), I don't.
> I was expecting both to have the same behaviour.
> 
> The code where I saw this had a die() function which received a va_list. 
> After calling this die() function, they "called" the macro va_close() 
> and this triggered the warning.
> 
I thought I fixed this!

It seems to be related to what happens after the call to the noreturn
function pointer. If there's nothing after it, it doesn't warn, but if
there's something after it, it does warn.

Here's another useful and interesting tidbit: if you put the noreturn
attribute inside the parentheses with the function name, or after the
parameter list, the problem goes away:

static void (NORETURN *die_routine)(int i); /* this works */
static void (*die_routine)(int i) NORETURN; /* so does this */
static NORETURN void (*die_routine)(int i); /* but not this */
static void NORETURN (*die_routine)(int i); /* and not this */

The reason is that, when clang sees the noreturn in the second two
cases, it hasn't yet seen the whole function header yet, so it tries (in
vain) to apply it to the return type. What we really want is for clang
to try to apply it to the function type, not the type it returns. I need
to figure this out anyway, so calling convention attributes work
properly in my future patches.

Chip

From rideau3 at gmail.com  Thu Dec 17 18:29:30 2009
From: rideau3 at gmail.com (Sean Hunt)
Date: Thu, 17 Dec 2009 17:29:30 -0700
Subject: [cfe-dev] Fwd: Re:  Invalid noreturn
Message-ID: <4B2ACCEA.9060801@gmail.com>

On 12/17/2009 03:35 PM, Charles Davis wrote:

>  I thought I fixed this!
>
>  It seems to be related to what happens after the call to the noreturn
>  function pointer. If there's nothing after it, it doesn't warn, but if
>  there's something after it, it does warn.
>
>  Here's another useful and interesting tidbit: if you put the noreturn
>  attribute inside the parentheses with the function name, or after the
>  parameter list, the problem goes away:
>
>  static void (NORETURN *die_routine)(int i); /* this works */
>  static void (*die_routine)(int i) NORETURN; /* so does this */
>  static NORETURN void (*die_routine)(int i); /* but not this */
>  static void NORETURN (*die_routine)(int i); /* and not this */
>
>  The reason is that, when clang sees the noreturn in the second two
>  cases, it hasn't yet seen the whole function header yet, so it tries (in
>  vain) to apply it to the return type. What we really want is for clang
>  to try to apply it to the function type, not the type it returns. I need
>  to figure this out anyway, so calling convention attributes work
>  properly in my future patches.
>
>  Chip
I think clang needs to be able to attach attributes to the declarator
itself, rather than the declaration. C++0x encourages this
interpretation (but, interestingly enough, not for [[noreturn]].
Possibly a defect?).

Sean


From cadaker at gmail.com  Fri Dec 18 04:11:02 2009
From: cadaker at gmail.com (=?ISO-8859-1?Q?Christian_Ad=E5ker?=)
Date: Fri, 18 Dec 2009 11:11:02 +0100
Subject: [cfe-dev] -Wfatal-errors
Message-ID: <199d10ce0912180211w57e9d831v5b16713fdcb110ed@mail.gmail.com>

Hi.

I was looking through the TODO file for some simple way of
contributing to clang, and saw a note about the -Wfatal-errors flag.
It turned out to be pretty straightforward to fix (by looking at
-Werror), but I thought I'd send the patch here for comments in case
I've missed something.
If everything's fine I'll do the -Wfatal-errors= version too. That
should be pretty much mimicking -Werror=, right?

//Christian Ad?ker
-------------- next part --------------
Index: include/clang/Basic/Diagnostic.h
===================================================================
--- include/clang/Basic/Diagnostic.h	(revision 91675)
+++ include/clang/Basic/Diagnostic.h	(working copy)
@@ -178,6 +178,7 @@
   unsigned char AllExtensionsSilenced; // Used by __extension__
   bool IgnoreAllWarnings;        // Ignore all warnings: -w
   bool WarningsAsErrors;         // Treat warnings like errors:
+  bool ErrorsAsFatal;            // Treat errors like fatal errors.
   bool SuppressSystemWarnings;   // Suppress warnings in system headers.
   bool SuppressAllDiagnostics;   // Suppress all diagnostics.
   ExtensionHandling ExtBehavior; // Map extensions onto warnings or errors?
@@ -260,6 +261,11 @@
   void setWarningsAsErrors(bool Val) { WarningsAsErrors = Val; }
   bool getWarningsAsErrors() const { return WarningsAsErrors; }
 
+  // setErrorsAsFatal - When set to true, any error reported is made a
+  // fatal error.
+  void setErrorsAsFatal(bool Val) { ErrorsAsFatal = Val; }
+  bool getErrorsAsFatal() const { return ErrorsAsFatal; }
+
   /// setSuppressSystemWarnings - When set to true mask warnings that
   /// come from system headers.
   void setSuppressSystemWarnings(bool Val) { SuppressSystemWarnings = Val; }
Index: lib/Frontend/Warnings.cpp
===================================================================
--- lib/Frontend/Warnings.cpp	(revision 91675)
+++ lib/Frontend/Warnings.cpp	(working copy)
@@ -47,7 +47,7 @@
   else
     Diags.setExtensionHandlingBehavior(Diagnostic::Ext_Ignore);
 
-  // FIXME: -Wfatal-errors / -Wfatal-errors=foo
+  // FIXME: -Wfatal-errors=foo
 
   for (unsigned i = 0, e = Opts.Warnings.size(); i != e; ++i) {
     const std::string &Opt = Opts.Warnings[i];
@@ -98,6 +98,12 @@
       OptStart = Specifier;
     }
 
+    // -Wfatal-errors is yet another special case.
+    if (OptEnd-OptStart == 12 && memcmp(OptStart, "fatal-errors", 12) == 0) {
+      Diags.setErrorsAsFatal(isPositive);
+      continue;
+    }
+
     if (Diags.setDiagnosticGroupMapping(OptStart, Mapping))
       Diags.Report(diag::warn_unknown_warning_option) << ("-W" + Opt);
   }
Index: lib/Basic/Diagnostic.cpp
===================================================================
--- lib/Basic/Diagnostic.cpp	(revision 91675)
+++ lib/Basic/Diagnostic.cpp	(working copy)
@@ -203,6 +203,7 @@
   AllExtensionsSilenced = 0;
   IgnoreAllWarnings = false;
   WarningsAsErrors = false;
+  ErrorsAsFatal = false;
   SuppressSystemWarnings = false;
   SuppressAllDiagnostics = false;
   ExtBehavior = Ext_Ignore;
@@ -329,6 +330,8 @@
     break;
   case diag::MAP_ERROR:
     Result = Diagnostic::Error;
+    if (ErrorsAsFatal)
+      Result = Diagnostic::Fatal;
     break;
   case diag::MAP_FATAL:
     Result = Diagnostic::Fatal;
@@ -349,6 +352,8 @@
 
     if (WarningsAsErrors)
       Result = Diagnostic::Error;
+    if (Result == Diagnostic::Error && ErrorsAsFatal)
+      Result = Diagnostic::Fatal;
     break;
 
   case diag::MAP_WARNING_NO_WERROR:

From abramobagnara at tin.it  Fri Dec 18 11:10:06 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri, 18 Dec 2009 18:10:06 +0100
Subject: [cfe-dev] Source rewrite
In-Reply-To: <6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
Message-ID: <4B2BB76E.70103@tin.it>

>> As I write above, what I need is that the AST built from:
>>
>> int p() {
>>  int a = 3;
>>  /* #instrument(a)# */
>> }
>>
>> is as if the source read was:
>>
>> int p() {
>>  int a = 3;
>>  instrument(a);
>> }
> 
> 
> Oh, interesting. You'll probably need to each the preprocessor how to
> parse inside these comments. One option might be to treat such comments
> similarly to macro expansion, so that processing the comment
> 
>   /* #instrument(a)# */
> 
> consumes the comment and then pushes a new lexer that will point into a
> buffer containing
> 
>   instrument(a)
> 
> just like processing
> 
>   FOO
> 
> where there is a macro definition
> 
>   #define FOO instrument(a)
> 
> will create a new lexer pointing into a buffer containing
> 
>   instrument(a)

I've done it and it "almost" works...

The problem I see is that the pushed TokenLexer is used only *after* the
first token after the comment is Lexed and not just after the skipped
comment (because usually the comment is not a token to return).

This means that:

int x /* = 0 */;
int z;

is lexed as:

int x; = 0 int z;

instead of the wished way.

Now I'm stuck...

There is a way to cope with that?

My CommentHandler is written in this way:

void Comment_Converter::HandleComment(clang::Preprocessor &PP,
                                      clang::SourceRange Comment) {
  const clang::SourceManager &sm = PP.getSourceManager();
  const clang::LangOptions &lo = PP.getLangOptions();
  clang::SourceLocation begin = Comment.getBegin();
  clang::FileID fid = sm.getFileID(begin);
  const char* start = sm.getCharacterData(begin);
  const char* end = sm.getCharacterData(Comment.getEnd());
  if (start[1] == '*')
    end -= 2;
  start += 2;
  char saved = *end;
  *const_cast<char*>(end) = 0;
  clang::Lexer lexer(sm.getLocForStartOfFile(fid), lo,
                     sm.getBufferData(fid).first,
                     start, end);
  static std::vector<clang::Token> tokens;
  tokens.clear();
  clang::Token tok;
  while (1) {
    lexer.LexFromRawLexer(tok);
    if (tok.is(clang::tok::eof))
      break;
    if (tok.is(clang::tok::identifier))
      tok.setKind(PP.LookUpIdentifierInfo(tok)->getTokenID());
    tokens.push_back(tok);
  }
  *const_cast<char*>(end) = saved;
  PP.EnterTokenStream(tokens.data(), tokens.size(), false, false);
}



From clattner at apple.com  Mon Dec 21 02:17:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 21 Dec 2009 00:17:16 -0800
Subject: [cfe-dev] -Wfatal-errors
In-Reply-To: <199d10ce0912180211w57e9d831v5b16713fdcb110ed@mail.gmail.com>
References: <199d10ce0912180211w57e9d831v5b16713fdcb110ed@mail.gmail.com>
Message-ID: <2ADDCA9F-9E1B-4312-9720-5F79986ECFB5@apple.com>


On Dec 18, 2009, at 2:11 AM, Christian Ad?ker wrote:

> Hi.
> 
> I was looking through the TODO file for some simple way of
> contributing to clang, and saw a note about the -Wfatal-errors flag.
> It turned out to be pretty straightforward to fix (by looking at
> -Werror), but I thought I'd send the patch here for comments in case
> I've missed something.

I don't think this is quite right: -pedantic-errors can map to errors as well in the MAP_IGNORE case right above it.  It's close though!

> If everything's fine I'll do the -Wfatal-errors= version too. That
> should be pretty much mimicking -Werror=, right?

Yep, exactly, should be very straight-forward.

Thanks for working on this!

-Chris

From clattner at apple.com  Mon Dec 21 12:05:03 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 21 Dec 2009 10:05:03 -0800
Subject: [cfe-dev] Fwd: New LLVM Blog
References: <746984EB-D8F9-4722-B267-36982C512DC4@apple.com>
Message-ID: <107ED021-082B-48B4-923B-466DF2AA4774@apple.com>

FYI to this list too :)

-Chris

Begin forwarded message:

> From: Chris Lattner <clattner at apple.com>
> Date: December 21, 2009 12:13:39 AM PST
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Subject: New LLVM Blog
> 
> Hi All,
> 
> A few of us got together and started an official LLVM (and its sub-projects) blog:
>  http://blog.llvm.org/
> 
> I think that a blog is a potentially great way to cover some areas of LLVM that we're lacking in the community:
> 
> 1. A place to describe cool new features and enhancements (which we can link to from the release notes).
> 2. Description of the motivation behind major API changes.
> 3. Higher level algorithmic descriptions.
> 4. A place for people to write about how they're *using* LLVM
> 5. a place for expanded information like version of http://llvm.org/ProjectsWithLLVM/ and http://llvm.org/Users.html
> 6. Updates on major accomplishments for sub-projects that are still in development (clang, dragonegg, MC, etc).
> 
> More than anything else, while LLVM is a highly dynamic project, our web page isn't.  I'm hoping to add sidebars to the llvm.org and clang.llvm.org web page that will show the blog feeds to get some of this information more visible.
> 
> In any case, for it to be successful, we need writers!  If you'd like to write an entry, please let me know. The only request that I have is that the entries be about things that you have *done* and are checked in, not about crazy ideas.  Once the crazy idea manifests as something great, it can show up on the blog :)
> 
> -Chris
> 

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

From cadaker at gmail.com  Mon Dec 21 14:11:45 2009
From: cadaker at gmail.com (=?ISO-8859-1?Q?Christian_Ad=E5ker?=)
Date: Mon, 21 Dec 2009 21:11:45 +0100
Subject: [cfe-dev] -Wfatal-errors
In-Reply-To: <2ADDCA9F-9E1B-4312-9720-5F79986ECFB5@apple.com>
References: <199d10ce0912180211w57e9d831v5b16713fdcb110ed@mail.gmail.com>
	<2ADDCA9F-9E1B-4312-9720-5F79986ECFB5@apple.com>
Message-ID: <199d10ce0912211211p69595a59p611e17c8554041e@mail.gmail.com>

On Mon, Dec 21, 2009 at 9:17 AM, Chris Lattner <clattner at apple.com> wrote:
>
> On Dec 18, 2009, at 2:11 AM, Christian Ad?ker wrote:
>
>> Hi.
>>
>> I was looking through the TODO file for some simple way of
>> contributing to clang, and saw a note about the -Wfatal-errors flag.
>> It turned out to be pretty straightforward to fix (by looking at
>> -Werror), but I thought I'd send the patch here for comments in case
>> I've missed something.
>
> I don't think this is quite right: -pedantic-errors can map to errors as well in the MAP_IGNORE case right above it. ?It's close though!

Oops, that's right. Fixed. However, -Werror doesn't affect the
-pedantic warnings in that way. Shouldn't they be similar?

Also, I've implemented -Wfatal-errors=foo. However, I'm not quite sure
how -Wno-fatal-errors=foo should work. In this patch, it always turns
foo into an error, even if -Werror is not in effect. Is that ok?

//Christian
-------------- next part --------------
Index: include/clang/Basic/Diagnostic.h
===================================================================
--- include/clang/Basic/Diagnostic.h	(revision 91836)
+++ include/clang/Basic/Diagnostic.h	(working copy)
@@ -76,7 +76,10 @@
 
       /// Map this diagnostic to "warning", but make it immune to -Werror.  This
       /// happens when you specify -Wno-error=foo.
-      MAP_WARNING_NO_WERROR = 5
+      MAP_WARNING_NO_WERROR = 5,
+      /// Map this diagnostic to "error", but make it immune to -Wfatal-errors.
+      /// This happens for -Wno-fatal-errors=foo.
+      MAP_ERROR_NO_WFATAL = 6
     };
   }
 
@@ -178,6 +181,7 @@
   unsigned char AllExtensionsSilenced; // Used by __extension__
   bool IgnoreAllWarnings;        // Ignore all warnings: -w
   bool WarningsAsErrors;         // Treat warnings like errors:
+  bool ErrorsAsFatal;            // Treat errors like fatal errors.
   bool SuppressSystemWarnings;   // Suppress warnings in system headers.
   bool SuppressAllDiagnostics;   // Suppress all diagnostics.
   ExtensionHandling ExtBehavior; // Map extensions onto warnings or errors?
@@ -260,6 +264,11 @@
   void setWarningsAsErrors(bool Val) { WarningsAsErrors = Val; }
   bool getWarningsAsErrors() const { return WarningsAsErrors; }
 
+  /// setErrorsAsFatal - When set to true, any error reported is made a
+  /// fatal error.
+  void setErrorsAsFatal(bool Val) { ErrorsAsFatal = Val; }
+  bool getErrorsAsFatal() const { return ErrorsAsFatal; }
+
   /// setSuppressSystemWarnings - When set to true mask warnings that
   /// come from system headers.
   void setSuppressSystemWarnings(bool Val) { SuppressSystemWarnings = Val; }
Index: lib/Frontend/Warnings.cpp
===================================================================
--- lib/Frontend/Warnings.cpp	(revision 91836)
+++ lib/Frontend/Warnings.cpp	(working copy)
@@ -47,8 +47,6 @@
   else
     Diags.setExtensionHandlingBehavior(Diagnostic::Ext_Ignore);
 
-  // FIXME: -Wfatal-errors / -Wfatal-errors=foo
-
   for (unsigned i = 0, e = Opts.Warnings.size(); i != e; ++i) {
     const std::string &Opt = Opts.Warnings[i];
     const char *OptStart = &Opt[0];
@@ -98,6 +96,31 @@
       OptStart = Specifier;
     }
 
+    // -Wfatal-errors is yet another special case.
+    if (OptEnd-OptStart >= 12 && memcmp(OptStart, "fatal-errors", 12) == 0) {
+      const char* Specifier = 0;
+      if (OptEnd-OptStart != 12) {
+        if ((OptStart[12] != '=' && OptStart[12] != '-') ||
+            OptEnd-OptStart == 13) {
+          fprintf(stderr,
+                  "warning: unknown -Wfatal-errors warning specifier: -W%s\n",
+                  Opt.c_str());
+          continue;
+        }
+        Specifier = OptStart + 13;
+      }
+
+      if (Specifier == 0) {
+        Diags.setErrorsAsFatal(isPositive);
+        continue;
+      }
+
+      // -Wfatal-errors=foo maps foo to Fatal, -Wno-fatal-errors=foo
+      // maps it to Error.
+      Mapping = isPositive ? diag::MAP_FATAL : diag::MAP_ERROR_NO_WFATAL;
+      OptStart = Specifier;
+    }
+
     if (Diags.setDiagnosticGroupMapping(OptStart, Mapping))
       Diags.Report(diag::warn_unknown_warning_option) << ("-W" + Opt);
   }
Index: lib/Basic/Diagnostic.cpp
===================================================================
--- lib/Basic/Diagnostic.cpp	(revision 91836)
+++ lib/Basic/Diagnostic.cpp	(working copy)
@@ -203,6 +203,7 @@
   AllExtensionsSilenced = 0;
   IgnoreAllWarnings = false;
   WarningsAsErrors = false;
+  ErrorsAsFatal = false;
   SuppressSystemWarnings = false;
   SuppressAllDiagnostics = false;
   ExtBehavior = Ext_Ignore;
@@ -326,9 +327,13 @@
       return Diagnostic::Ignored;
     Result = Diagnostic::Warning;
     if (ExtBehavior == Ext_Error) Result = Diagnostic::Error;
+    if (Result == Diagnostic::Error && ErrorsAsFatal)
+      Result = Diagnostic::Fatal;
     break;
   case diag::MAP_ERROR:
     Result = Diagnostic::Error;
+    if (ErrorsAsFatal)
+      Result = Diagnostic::Fatal;
     break;
   case diag::MAP_FATAL:
     Result = Diagnostic::Fatal;
@@ -349,6 +354,8 @@
 
     if (WarningsAsErrors)
       Result = Diagnostic::Error;
+    if (Result == Diagnostic::Error && ErrorsAsFatal)
+      Result = Diagnostic::Fatal;
     break;
 
   case diag::MAP_WARNING_NO_WERROR:
@@ -361,6 +368,12 @@
       return Diagnostic::Ignored;
 
     break;
+
+  case diag::MAP_ERROR_NO_WFATAL:
+    // Diagnostics specified as -Wno-fatal-error=foo should be errors, but
+    // unaffected by -Wfatal-errors.
+    Result = Diagnostic::Error;
+    break;
   }
 
   // Okay, we're about to return this as a "diagnostic to emit" one last check:

From rahulgarg44 at gmail.com  Mon Dec 21 16:41:11 2009
From: rahulgarg44 at gmail.com (Rahul Garg)
Date: Mon, 21 Dec 2009 17:41:11 -0500
Subject: [cfe-dev] ast-dump option in clang-cc not working?
Message-ID: <ad0cc6f00912211441xddb4930t751db73ded3d7008@mail.gmail.com>

Hi.
I am trying to understand clang and was trying to do clang-cc hello.c
-ast-dump. clang and llvm was built from LLVM 2.6 release and am on Ubuntu
9.04 64-bit. Any ideas what may be the problem?
I get the follwing output indicating error:

typedef __int128_t __int128_t;
typedef __uint128_t __uint128_t;
struct __va_list_tag {
    unsigned int gp_offset;
    unsigned int fp_offset;
    void *overflow_arg_area;
    void *reg_save_area;
};
typedef struct __va_list_tag __va_list_tag;
typedef __va_list_tag __builtin_va_list[1];
0   clang-cc        0x0000000000efa8ff
1   clang-cc        0x0000000000efc611
2   libpthread.so.0 0x00007f58094a1080
3   clang-cc        0x000000000079a6e0
4   clang-cc        0x00000000007a8fc4
5   clang-cc        0x00000000007a50db
6   clang-cc        0x0000000000763f96
7   clang-cc        0x000000000076510c
8   clang-cc        0x0000000000763e98
9   clang-cc        0x0000000000764b6b
10  clang-cc        0x000000000043891d
11  clang-cc        0x00000000006402fb
12  clang-cc        0x0000000000427ff9
13  clang-cc        0x0000000000430f1a main + 4906
14  libc.so.6       0x00007f58087905a6 __libc_start_main + 230
15  clang-cc        0x0000000000425b09
Stack dump:
0.    Program arguments: clang-cc -ast-dump hello.c
1.    <eof> parser at end of file
Segmentation fault
typedef __int128_t __int128_t;
typedef __uint128_t __uint128_t;
struct __va_list_tag {
    unsigned int gp_offset;
    unsigned int fp_offset;
    void *overflow_arg_area;
    void *reg_save_area;
};
typedef struct __va_list_tag __va_list_tag;
typedef __va_list_tag __builtin_va_list[1];
0   clang-cc        0x0000000000efa8ff
1   clang-cc        0x0000000000efc611
2   libpthread.so.0 0x00007f58094a1080
3   clang-cc        0x000000000079a6e0
4   clang-cc        0x00000000007a8fc4
5   clang-cc        0x00000000007a50db
6   clang-cc        0x0000000000763f96
7   clang-cc        0x000000000076510c
8   clang-cc        0x0000000000763e98
9   clang-cc        0x0000000000764b6b
10  clang-cc        0x000000000043891d
11  clang-cc        0x00000000006402fb
12  clang-cc        0x0000000000427ff9
13  clang-cc        0x0000000000430f1a main + 4906
14  libc.so.6       0x00007f58087905a6 __libc_start_main + 230
15  clang-cc        0x0000000000425b09
Stack dump:
0.    Program arguments: clang-cc -ast-dump hello.c
1.    <eof> parser at end of file
Segmentation fault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091221/37d9ce56/attachment.html 

From fjahanian at apple.com  Mon Dec 21 16:54:40 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Mon, 21 Dec 2009 14:54:40 -0800
Subject: [cfe-dev] ast-dump option in clang-cc not working?
In-Reply-To: <ad0cc6f00912211441xddb4930t751db73ded3d7008@mail.gmail.com>
References: <ad0cc6f00912211441xddb4930t751db73ded3d7008@mail.gmail.com>
Message-ID: <EB8BF4C5-5EB0-46F5-AFEA-C7F11EA24730@apple.com>

We generally have not kept up-to-date with -ast-dump.
But a simple hello.c seems to work for me:

% cat hello.c
#include <stdio.h>

int main() {
	printf("HELLO");
}

$clang -cc1 -ast-dump hello.c


typedef __int128_t __int128_t;
typedef __uint128_t __uint128_t;
struct __va_list_tag {
     unsigned int gp_offset;
     unsigned int fp_offset;
     void *overflow_arg_area;
     void *reg_save_area;
};
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;

...


- Fariborz





On Dec 21, 2009, at 2:41 PM, Rahul Garg wrote:

> Hi.
> I am trying to understand clang and was trying to do clang-cc  
> hello.c -ast-dump. clang and llvm was built from LLVM 2.6 release  
> and am on Ubuntu 9.04 64-bit. Any ideas what may be the problem?
> I get the follwing output indicating error:
>
> typedef __int128_t __int128_t;
> typedef __uint128_t __uint128_t;
> struct __va_list_tag {
>     unsigned int gp_offset;
>     unsigned int fp_offset;
>     void *overflow_arg_area;

From etherzhhb at gmail.com  Mon Dec 21 21:23:46 2009
From: etherzhhb at gmail.com (ether zhhb)
Date: Tue, 22 Dec 2009 11:23:46 +0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <4B2BB76E.70103@tin.it>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<4B2BB76E.70103@tin.it>
Message-ID: <5f72161f0912211923y78ca24e4m775448c02d51e4be@mail.gmail.com>

hi,

its there any simple example that shows us how to rewrite the source
code that clang just parsed?

best regards

--ether

On Sat, Dec 19, 2009 at 1:10 AM, Abramo Bagnara <abramobagnara at tin.it> wrote:
>>> As I write above, what I need is that the AST built from:
>>>
>>> int p() {
>>> ?int a = 3;
>>> ?/* #instrument(a)# */
>>> }
>>>
>>> is as if the source read was:
>>>
>>> int p() {
>>> ?int a = 3;
>>> ?instrument(a);
>>> }
>>
>>
>> Oh, interesting. You'll probably need to each the preprocessor how to
>> parse inside these comments. One option might be to treat such comments
>> similarly to macro expansion, so that processing the comment
>>
>> ? /* #instrument(a)# */
>>
>> consumes the comment and then pushes a new lexer that will point into a
>> buffer containing
>>
>> ? instrument(a)
>>
>> just like processing
>>
>> ? FOO
>>
>> where there is a macro definition
>>
>> ? #define FOO instrument(a)
>>
>> will create a new lexer pointing into a buffer containing
>>
>> ? instrument(a)
>
> I've done it and it "almost" works...
>
> The problem I see is that the pushed TokenLexer is used only *after* the
> first token after the comment is Lexed and not just after the skipped
> comment (because usually the comment is not a token to return).
>
> This means that:
>
> int x /* = 0 */;
> int z;
>
> is lexed as:
>
> int x; = 0 int z;
>
> instead of the wished way.
>
> Now I'm stuck...
>
> There is a way to cope with that?
>
> My CommentHandler is written in this way:
>
> void Comment_Converter::HandleComment(clang::Preprocessor &PP,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?clang::SourceRange Comment) {
> ?const clang::SourceManager &sm = PP.getSourceManager();
> ?const clang::LangOptions &lo = PP.getLangOptions();
> ?clang::SourceLocation begin = Comment.getBegin();
> ?clang::FileID fid = sm.getFileID(begin);
> ?const char* start = sm.getCharacterData(begin);
> ?const char* end = sm.getCharacterData(Comment.getEnd());
> ?if (start[1] == '*')
> ? ?end -= 2;
> ?start += 2;
> ?char saved = *end;
> ?*const_cast<char*>(end) = 0;
> ?clang::Lexer lexer(sm.getLocForStartOfFile(fid), lo,
> ? ? ? ? ? ? ? ? ? ? sm.getBufferData(fid).first,
> ? ? ? ? ? ? ? ? ? ? start, end);
> ?static std::vector<clang::Token> tokens;
> ?tokens.clear();
> ?clang::Token tok;
> ?while (1) {
> ? ?lexer.LexFromRawLexer(tok);
> ? ?if (tok.is(clang::tok::eof))
> ? ? ?break;
> ? ?if (tok.is(clang::tok::identifier))
> ? ? ?tok.setKind(PP.LookUpIdentifierInfo(tok)->getTokenID());
> ? ?tokens.push_back(tok);
> ?}
> ?*const_cast<char*>(end) = saved;
> ?PP.EnterTokenStream(tokens.data(), tokens.size(), false, false);
> }
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From gwk.lists at gmail.com  Tue Dec 22 16:53:47 2009
From: gwk.lists at gmail.com (George King)
Date: Tue, 22 Dec 2009 14:53:47 -0800
Subject: [cfe-dev] make update not updating clang svn?
Message-ID: <BE309558-D029-463B-8D1C-AB3F4C0857DC@gmail.com>

Hi list,

According to http://clang.llvm.org/get_started.html:

You can update your toplevel LLVM project and all (possibly unrelated) projects inside it with make update. This will run svn update on all subdirectories related to subversion.

However after following the check out instructions, I observed the following behavior:

gk ~/external/llvm > make update
svn  update /Users/gk/external/llvm
U    /Users/gk/external/llvm/test/CodeGen/X86/break-sse-dep.ll
... (more U ... lines)
Updated to revision 91929.

gk ~/external/llvm > cd tools/clang
gk ~/external/llvm/tools/clang > svn update
U    test/Lexer/char-escapes.c
... (many more U ... lines)
Updated to revision 91930.

gk ~/external/llvm/tools/clang > cd ../..
gk ~/external/llvm > svn update
At revision 91930.


'make update' did not appear to run 'svn update' for the tools/clang directory. Otherwise I would see "svn update /Users/gk/external/llvm/tools/clang" output, right? I realize that this looks a little ambiguous because of the revision numbers 91929 and 91930, but I don't think that's the issue; there were hundreds of files updated in the clang tree, which I doubt were committed in the interim between commands. 

Does 'make update' work as advertised for others?

Thank you,

George

From clattner at apple.com  Tue Dec 22 16:58:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 22 Dec 2009 14:58:45 -0800
Subject: [cfe-dev] make update not updating clang svn?
In-Reply-To: <BE309558-D029-463B-8D1C-AB3F4C0857DC@gmail.com>
References: <BE309558-D029-463B-8D1C-AB3F4C0857DC@gmail.com>
Message-ID: <557D8988-A3B0-48C7-9F93-F674C46FB4FE@apple.com>


On Dec 22, 2009, at 2:53 PM, George King wrote:

> Hi list,
>
> According to http://clang.llvm.org/get_started.html:
>
> You can update your toplevel LLVM project and all (possibly  
> unrelated) projects inside it with make update. This will run svn  
> update on all subdirectories related to subversion.

Someone on IRC was claiming that this was because tools/clang was in  
the svnignore of the llvm tree.  This doesn't make a lot of sense to  
me, but I don't know how to fix it.  If some else does, please go for  
it.

-Chris

>
> However after following the check out instructions, I observed the  
> following behavior:
>
> gk ~/external/llvm > make update
> svn  update /Users/gk/external/llvm
> U    /Users/gk/external/llvm/test/CodeGen/X86/break-sse-dep.ll
> ... (more U ... lines)
> Updated to revision 91929.
>
> gk ~/external/llvm > cd tools/clang
> gk ~/external/llvm/tools/clang > svn update
> U    test/Lexer/char-escapes.c
> ... (many more U ... lines)
> Updated to revision 91930.
>
> gk ~/external/llvm/tools/clang > cd ../..
> gk ~/external/llvm > svn update
> At revision 91930.
>
>
> 'make update' did not appear to run 'svn update' for the tools/clang  
> directory. Otherwise I would see "svn update /Users/gk/external/llvm/ 
> tools/clang" output, right? I realize that this looks a little  
> ambiguous because of the revision numbers 91929 and 91930, but I  
> don't think that's the issue; there were hundreds of files updated  
> in the clang tree, which I doubt were committed in the interim  
> between commands.
>
> Does 'make update' work as advertised for others?
>
> Thank you,
>
> George
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From mtzrgb at gmail.com  Tue Dec 22 17:01:19 2009
From: mtzrgb at gmail.com (moataz ragab)
Date: Wed, 23 Dec 2009 01:01:19 +0200
Subject: [cfe-dev] linking external components to clang
Message-ID: <6dcf3dab0912221501l60ddd4edid0f376c700b86f1@mail.gmail.com>

Hi,

I would like to link non-clang, non-llvm library to my modified version of
clang.  I can't easily find which variable to add to the make file to get it
linked using the default llvm/clang build.

Thanks,
Moataz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091223/7c078b80/attachment.html 

From clattner at apple.com  Tue Dec 22 17:13:49 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 22 Dec 2009 15:13:49 -0800
Subject: [cfe-dev] -Wfatal-errors
In-Reply-To: <199d10ce0912211211p69595a59p611e17c8554041e@mail.gmail.com>
References: <199d10ce0912180211w57e9d831v5b16713fdcb110ed@mail.gmail.com>
	<2ADDCA9F-9E1B-4312-9720-5F79986ECFB5@apple.com>
	<199d10ce0912211211p69595a59p611e17c8554041e@mail.gmail.com>
Message-ID: <1A4CF9B5-DC3F-4402-A99B-9F33C013726D@apple.com>


On Dec 21, 2009, at 12:11 PM, Christian Ad?ker wrote:

> On Mon, Dec 21, 2009 at 9:17 AM, Chris Lattner <clattner at apple.com>  
> wrote:
>>
>> On Dec 18, 2009, at 2:11 AM, Christian Ad?ker wrote:
>>
>>> Hi.
>>>
>>> I was looking through the TODO file for some simple way of
>>> contributing to clang, and saw a note about the -Wfatal-errors flag.
>>> It turned out to be pretty straightforward to fix (by looking at
>>> -Werror), but I thought I'd send the patch here for comments in case
>>> I've missed something.
>>
>> I don't think this is quite right: -pedantic-errors can map to  
>> errors as well in the MAP_IGNORE case right above it.  It's close  
>> though!
>
> Oops, that's right. Fixed. However, -Werror doesn't affect the
> -pedantic warnings in that way. Shouldn't they be similar?
>
> Also, I've implemented -Wfatal-errors=foo. However, I'm not quite sure
> how -Wno-fatal-errors=foo should work. In this patch, it always turns
> foo into an error, even if -Werror is not in effect. Is that ok?

Looks great, applied here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091221/025732.html

A nice cleanup in that code would be to switch it to produce  
diagnostics for the error cases instead of using printf, would you be  
interested in tackling that too?

-Chris

From dgregor at apple.com  Tue Dec 22 17:48:42 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 22 Dec 2009 15:48:42 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <5f72161f0912211923y78ca24e4m775448c02d51e4be@mail.gmail.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<4B2BB76E.70103@tin.it>
	<5f72161f0912211923y78ca24e4m775448c02d51e4be@mail.gmail.com>
Message-ID: <3869703C-122D-4C9B-BBF9-FF78B5E230F2@apple.com>


On Dec 21, 2009, at 7:23 PM, ether zhhb wrote:

> hi,
>
> its there any simple example that shows us how to rewrite the source
> code that clang just parsed?


The simplest rewriter that works on parsed ASTs is probably the blocks  
rewriter, in lib/Frontend/RewriteBlocks.cpp

	- Doug

From dgregor at apple.com  Tue Dec 22 17:54:03 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 22 Dec 2009 15:54:03 -0800
Subject: [cfe-dev] Newbie question : instrumenting code
In-Reply-To: <ad0cc6f00912130928o291f9cdco9a5f962f87f2a44c@mail.gmail.com>
References: <ad0cc6f00912130928o291f9cdco9a5f962f87f2a44c@mail.gmail.com>
Message-ID: <254DE36A-8E0E-43E4-A50F-B9BECFFFEF97@apple.com>


On Dec 13, 2009, at 9:28 AM, Rahul Garg wrote:

> Hi.
>
> I am new to Clang and somewhat new to LLVM. I am doing a project  
> where I need to instrument C code to add some profiling information  
> such as timers and iteration counts of loops to some of the  
> functions and then it will be compiled using clang+llvm. The  
> transformation need not be source to source. All I am looking for is  
> the ability to add instrumentation at some point during the  
> compilation process. Is it reasonable to attempt to modify Clang so  
> that it adds timers and logging calls at the places I need? Or  
> should I be looking at some other part of the LLVM stack?


You will probably want to extend Clang's CodeGen to create LLVM IR for  
the timers/instrumentation directly. That will make it easy to tie  
that instrumentation to specific AST elements, which might be useful  
if you decide that you also want to add instrumentation pragmas or  
attributes that show up in the source code.

If you're interesting in perform more low-level instrumentation, you  
could consider adding an LLVM pass.

	- Doug

From fjahanian at apple.com  Tue Dec 22 18:13:43 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Tue, 22 Dec 2009 16:13:43 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <3869703C-122D-4C9B-BBF9-FF78B5E230F2@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<4B2BB76E.70103@tin.it>
	<5f72161f0912211923y78ca24e4m775448c02d51e4be@mail.gmail.com>
	<3869703C-122D-4C9B-BBF9-FF78B5E230F2@apple.com>
Message-ID: <B4F822ED-4BD9-4F85-B9D5-1AC2FC12327D@apple.com>


On Dec 22, 2009, at 3:48 PM, Douglas Gregor wrote:

>
> On Dec 21, 2009, at 7:23 PM, ether zhhb wrote:
>
>> hi,
>>
>> its there any simple example that shows us how to rewrite the source
>> code that clang just parsed?
>
>
> The simplest rewriter that works on parsed ASTs is probably the blocks
> rewriter, in lib/Frontend/RewriteBlocks.cpp

Above source is obsolete. All rewriting code is done in  lib/Frontend/ 
RewriteObjC.cpp nowadays.

- Fariborz

>
>
> 	- 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  Tue Dec 22 18:17:30 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Tue, 22 Dec 2009 16:17:30 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <B4F822ED-4BD9-4F85-B9D5-1AC2FC12327D@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<4B2BB76E.70103@tin.it>
	<5f72161f0912211923y78ca24e4m775448c02d51e4be@mail.gmail.com>
	<3869703C-122D-4C9B-BBF9-FF78B5E230F2@apple.com>
	<B4F822ED-4BD9-4F85-B9D5-1AC2FC12327D@apple.com>
Message-ID: <E50BE64A-9505-454D-99B0-58950A59AA6A@apple.com>


On Dec 22, 2009, at 4:13 PM, Fariborz Jahanian wrote:

>
> On Dec 22, 2009, at 3:48 PM, Douglas Gregor wrote:
>
>>
>> On Dec 21, 2009, at 7:23 PM, ether zhhb wrote:
>>
>>> hi,
>>>
>>> its there any simple example that shows us how to rewrite the source
>>> code that clang just parsed?
>>
>>
>> The simplest rewriter that works on parsed ASTs is probably the  
>> blocks
>> rewriter, in lib/Frontend/RewriteBlocks.cpp
>
> Above source is obsolete. All rewriting code is done in  lib/ 
> Frontend/RewriteObjC.cpp nowadays.

Should we just remove it, then? Or does it still have value?

	- Doug

From fjahanian at apple.com  Tue Dec 22 18:26:32 2009
From: fjahanian at apple.com (Fariborz Jahanian)
Date: Tue, 22 Dec 2009 16:26:32 -0800
Subject: [cfe-dev] Source rewrite
In-Reply-To: <E50BE64A-9505-454D-99B0-58950A59AA6A@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<4B2BB76E.70103@tin.it>
	<5f72161f0912211923y78ca24e4m775448c02d51e4be@mail.gmail.com>
	<3869703C-122D-4C9B-BBF9-FF78B5E230F2@apple.com>
	<B4F822ED-4BD9-4F85-B9D5-1AC2FC12327D@apple.com>
	<E50BE64A-9505-454D-99B0-58950A59AA6A@apple.com>
Message-ID: <0D63FF58-C1FD-4E5B-AD49-789C798FFD8C@apple.com>


On Dec 22, 2009, at 4:17 PM, Douglas Gregor wrote:

>
> On Dec 22, 2009, at 4:13 PM, Fariborz Jahanian wrote:
>
>>
>> On Dec 22, 2009, at 3:48 PM, Douglas Gregor wrote:
>>
>>>
>>> On Dec 21, 2009, at 7:23 PM, ether zhhb wrote:
>>>
>>>> hi,
>>>>
>>>> its there any simple example that shows us how to rewrite the  
>>>> source
>>>> code that clang just parsed?
>>>
>>>
>>> The simplest rewriter that works on parsed ASTs is probably the  
>>> blocks
>>> rewriter, in lib/Frontend/RewriteBlocks.cpp
>>
>> Above source is obsolete. All rewriting code is done in  lib/ 
>> Frontend/RewriteObjC.cpp nowadays.
>
> Should we just remove it, then? Or does it still have value?

Steve introduced it. He told me it is no longer in use. Let's get his  
confirmation before we act on it.

- Fariborz

>
>
> 	- Doug


From snaroff at apple.com  Tue Dec 22 18:35:59 2009
From: snaroff at apple.com (steve naroff)
Date: Tue, 22 Dec 2009 19:35:59 -0500
Subject: [cfe-dev] Source rewrite
In-Reply-To: <0D63FF58-C1FD-4E5B-AD49-789C798FFD8C@apple.com>
References: <4B2A1E8D.3040609@tin.it>
	<97D6924D-9CBC-451E-8160-739BD591DAAE@apple.com>
	<CCBAEAD7-9825-4DE9-BAE3-0BD66396E1B8@apple.com>
	<4B2A669D.8060406@tin.it>
	<6CE10684-7F01-4A21-828E-E1D54AFD4FB8@apple.com>
	<4B2BB76E.70103@tin.it>
	<5f72161f0912211923y78ca24e4m775448c02d51e4be@mail.gmail.com>
	<3869703C-122D-4C9B-BBF9-FF78B5E230F2@apple.com>
	<B4F822ED-4BD9-4F85-B9D5-1AC2FC12327D@apple.com>
	<E50BE64A-9505-454D-99B0-58950A59AA6A@apple.com>
	<0D63FF58-C1FD-4E5B-AD49-789C798FFD8C@apple.com>
Message-ID: <F4B7F279-D7E6-4E0E-AA7A-73625F207E24@apple.com>


On Dec 22, 2009, at 7:26 PM, Fariborz Jahanian wrote:

>
> On Dec 22, 2009, at 4:17 PM, Douglas Gregor wrote:
>
>>
>> On Dec 22, 2009, at 4:13 PM, Fariborz Jahanian wrote:
>>
>>>
>>> On Dec 22, 2009, at 3:48 PM, Douglas Gregor wrote:
>>>
>>>>
>>>> On Dec 21, 2009, at 7:23 PM, ether zhhb wrote:
>>>>
>>>>> hi,
>>>>>
>>>>> its there any simple example that shows us how to rewrite the
>>>>> source
>>>>> code that clang just parsed?
>>>>
>>>>
>>>> The simplest rewriter that works on parsed ASTs is probably the
>>>> blocks
>>>> rewriter, in lib/Frontend/RewriteBlocks.cpp
>>>
>>> Above source is obsolete. All rewriting code is done in  lib/
>>> Frontend/RewriteObjC.cpp nowadays.
>>
>> Should we just remove it, then? Or does it still have value?
>
> Steve introduced it. He told me it is no longer in use. Let's get his
> confirmation before we act on it.
>

It is vestigial (used back when we were prototyping blocks/rewriting).

Please feel free to remove it...

snaroff

> - Fariborz
>
>>
>>
>> 	- Doug
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


From cadaker at gmail.com  Wed Dec 23 03:00:00 2009
From: cadaker at gmail.com (=?ISO-8859-1?Q?Christian_Ad=E5ker?=)
Date: Wed, 23 Dec 2009 10:00:00 +0100
Subject: [cfe-dev] -Wfatal-errors
In-Reply-To: <1A4CF9B5-DC3F-4402-A99B-9F33C013726D@apple.com>
References: <199d10ce0912180211w57e9d831v5b16713fdcb110ed@mail.gmail.com>
	<2ADDCA9F-9E1B-4312-9720-5F79986ECFB5@apple.com>
	<199d10ce0912211211p69595a59p611e17c8554041e@mail.gmail.com>
	<1A4CF9B5-DC3F-4402-A99B-9F33C013726D@apple.com>
Message-ID: <199d10ce0912230100me78cb07i35e9ba66058cbea0@mail.gmail.com>

On Wed, Dec 23, 2009 at 12:13 AM, Chris Lattner <clattner at apple.com> wrote:
> A nice cleanup in that code would be to switch it to produce diagnostics for
> the error cases instead of using printf, would you be interested in tackling
> that too?

Sure. I also took the liberty of updating a few comments and the TODO.

//Christian
-------------- next part --------------
Index: TODO.txt
===================================================================
--- TODO.txt	(revision 91988)
+++ TODO.txt	(working copy)
@@ -69,7 +69,6 @@
 //===---------------------------------------------------------------------===//
 
 Options to support:
-   -Wfatal-errors
    -ftabstop=width
    -fpreprocessed mode.
    -nostdinc++
Index: include/clang/Basic/DiagnosticFrontendKinds.td
===================================================================
--- include/clang/Basic/DiagnosticFrontendKinds.td	(revision 91988)
+++ include/clang/Basic/DiagnosticFrontendKinds.td	(working copy)
@@ -219,4 +219,7 @@
 def warn_unknown_warning_option : Warning<
     "unknown warning option '%0'">,
     InGroup<DiagGroup<"unknown-warning-option"> >;
+def warn_unknown_warning_specifier : Warning<
+    "unknown %0 warning specifier: '%1'">,
+    InGroup<DiagGroup<"unknown-warning-option"> >;
 }
Index: lib/Frontend/Warnings.cpp
===================================================================
--- lib/Frontend/Warnings.cpp	(revision 91988)
+++ lib/Frontend/Warnings.cpp	(working copy)
@@ -13,12 +13,12 @@
 //
 // This file is responsible for handling all warning options. This includes
 // a number of -Wfoo options and their variants, which are driven by TableGen-
-// generated data, and the special cases -pedantic, -pedantic-errors, -w and
-// -Werror.
+// generated data, and the special cases -pedantic, -pedantic-errors, -w,
+// -Werror and -Wfatal-errors.
 //
 // Each warning option controls any number of actual warnings.
 // Given a warning option 'foo', the following are valid:
-//    -Wfoo, -Wno-foo, -Werror=foo
+//    -Wfoo, -Wno-foo, -Werror=foo, -Wfatal-errors=foo
 //
 #include "clang/Frontend/Utils.h"
 #include "clang/Basic/Diagnostic.h"
@@ -26,7 +26,6 @@
 #include "clang/Lex/LexDiagnostic.h"
 #include "clang/Frontend/DiagnosticOptions.h"
 #include "clang/Frontend/FrontendDiagnostic.h"
-#include <cstdio>
 #include <cstring>
 #include <utility>
 #include <algorithm>
@@ -79,8 +78,8 @@
       if (OptEnd-OptStart != 5) {  // Specifier must be present.
         if ((OptStart[5] != '=' && OptStart[5] != '-') ||
             OptEnd-OptStart == 6) {
-          fprintf(stderr, "warning: unknown -Werror warning specifier: -W%s\n",
-                  Opt.c_str());
+          Diags.Report(diag::warn_unknown_warning_specifier)
+            << "-Werror" << ("-W" + Opt);
           continue;
         }
         Specifier = OptStart+6;
@@ -102,9 +101,8 @@
       if (OptEnd-OptStart != 12) {
         if ((OptStart[12] != '=' && OptStart[12] != '-') ||
             OptEnd-OptStart == 13) {
-          fprintf(stderr,
-                  "warning: unknown -Wfatal-errors warning specifier: -W%s\n",
-                  Opt.c_str());
+          Diags.Report(diag::warn_unknown_warning_specifier)
+            << "-Wfatal-errors" << ("-W" + Opt);
           continue;
         }
         Specifier = OptStart + 13;

From mainmanmauricio at gmail.com  Wed Dec 23 06:57:33 2009
From: mainmanmauricio at gmail.com (Maurice Gittens)
Date: Wed, 23 Dec 2009 13:57:33 +0100
Subject: [cfe-dev] Attempt to fix incorrect diagnoses of
	diag::err_template_arg_too_large
Message-ID: <305911e30912230457j776e954do48ee3dc245cfa149@mail.gmail.com>

Hi,

without the following patch, clang incorrectly claims
that, for example, -128 does not fit in a signed char
when used as a template argument.

I found this when trying to use clang++ to parse a boost header
file.

I hope that you find it useful.

Kind regards,
Maurice


diff --git a/lib/Sema/SemaTemplate.cpp b/lib/Sema/SemaTemplate.cpp
index e6bd77d..2e260e0 100644
--- a/lib/Sema/SemaTemplate.cpp
+++ b/lib/Sema/SemaTemplate.cpp
@@ -2489,12 +2489,24 @@ bool
Sema::CheckTemplateArgument(NonTypeTemplateParmDecl *Param,
       // Check that we don't overflow the template parameter type.
       unsigned AllowedBits = Context.getTypeSize(IntegerType);
       if (Value.getActiveBits() > AllowedBits) {
-        Diag(Arg->getSourceRange().getBegin(),
-             diag::err_template_arg_too_large)
+        bool ConstantFits = false;
+
+        if (IntegerType->isSignedIntegerType()) {
+          llvm::APSInt TmpValue = Value;
+          TmpValue.extOrTrunc(AllowedBits);
+
+          if (TmpValue.isMinSignedValue())
+            ConstantFits = true;
+        }
+
+        if (!ConstantFits) {
+          Diag(Arg->getSourceRange().getBegin(),
+          diag::err_template_arg_too_large)
           << Value.toString(10) << Param->getType()
           << Arg->getSourceRange();
-        Diag(Param->getLocation(), diag::note_template_param_here);
-        return true;
+          Diag(Param->getLocation(), diag::note_template_param_here);
+          return true;
+        }
       }

       if (Value.getBitWidth() != AllowedBits)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091223/bc485ec8/attachment.html 

From filcab at gmail.com  Wed Dec 23 07:52:25 2009
From: filcab at gmail.com (Filipe Cabecinhas)
Date: Wed, 23 Dec 2009 13:52:25 +0000
Subject: [cfe-dev] make update not updating clang svn?
In-Reply-To: <557D8988-A3B0-48C7-9F93-F674C46FB4FE@apple.com>
References: <BE309558-D029-463B-8D1C-AB3F4C0857DC@gmail.com>
	<557D8988-A3B0-48C7-9F93-F674C46FB4FE@apple.com>
Message-ID: <4B322099.7090601@gmail.com>

Hi

I didn't see tools/clang in svn ignore...

Sometime ago I tracked that problem down to svn info... But now I tried 
to reproduce and make update worked... Weird.

Regards,

   Filipe


On 12/22/09 22:58, Chris Lattner wrote:
>
> On Dec 22, 2009, at 2:53 PM, George King wrote:
>
>> Hi list,
>>
>> According to http://clang.llvm.org/get_started.html:
>>
>> You can update your toplevel LLVM project and all (possibly
>> unrelated) projects inside it with make update. This will run svn
>> update on all subdirectories related to subversion.
>
> Someone on IRC was claiming that this was because tools/clang was in
> the svnignore of the llvm tree.  This doesn't make a lot of sense to
> me, but I don't know how to fix it.  If some else does, please go for
> it.
>
> -Chris
>
>>
>> However after following the check out instructions, I observed the
>> following behavior:
>>
>> gk ~/external/llvm>  make update
>> svn  update /Users/gk/external/llvm
>> U    /Users/gk/external/llvm/test/CodeGen/X86/break-sse-dep.ll
>> ... (more U ... lines)
>> Updated to revision 91929.
>>
>> gk ~/external/llvm>  cd tools/clang
>> gk ~/external/llvm/tools/clang>  svn update
>> U    test/Lexer/char-escapes.c
>> ... (many more U ... lines)
>> Updated to revision 91930.
>>
>> gk ~/external/llvm/tools/clang>  cd ../..
>> gk ~/external/llvm>  svn update
>> At revision 91930.
>>
>>
>> 'make update' did not appear to run 'svn update' for the tools/clang
>> directory. Otherwise I would see "svn update /Users/gk/external/llvm/
>> tools/clang" output, right? I realize that this looks a little
>> ambiguous because of the revision numbers 91929 and 91930, but I
>> don't think that's the issue; there were hundreds of files updated
>> in the clang tree, which I doubt were committed in the interim
>> between commands.
>>
>> Does 'make update' work as advertised for others?
>>
>> Thank you,
>>
>> George
>> _______________________________________________
>> 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

From eli.friedman at gmail.com  Wed Dec 23 11:53:05 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 23 Dec 2009 09:53:05 -0800
Subject: [cfe-dev] Attempt to fix incorrect diagnoses of
	diag::err_template_arg_too_large
In-Reply-To: <305911e30912230457j776e954do48ee3dc245cfa149@mail.gmail.com>
References: <305911e30912230457j776e954do48ee3dc245cfa149@mail.gmail.com>
Message-ID: <f5aa3e9b0912230953y3d6b2427qcdfa3eaca5bec5f7@mail.gmail.com>

On Wed, Dec 23, 2009 at 4:57 AM, Maurice Gittens
<mainmanmauricio at gmail.com> wrote:
> Hi,
>
> without the following patch, clang incorrectly claims
> that, for example, -128 does not fit in a signed char
> when used as a template argument.
>
> I found this when trying to use clang++ to parse a boost header
> file.
>
> I hope that you find it useful.

Interesting bug report, but the patch doesn't look right; I'll take a look.

-Eli

From clattner at apple.com  Wed Dec 23 12:54:00 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 23 Dec 2009 10:54:00 -0800
Subject: [cfe-dev] -Wfatal-errors
In-Reply-To: <199d10ce0912230100me78cb07i35e9ba66058cbea0@mail.gmail.com>
References: <199d10ce0912180211w57e9d831v5b16713fdcb110ed@mail.gmail.com>
	<2ADDCA9F-9E1B-4312-9720-5F79986ECFB5@apple.com>
	<199d10ce0912211211p69595a59p611e17c8554041e@mail.gmail.com>
	<1A4CF9B5-DC3F-4402-A99B-9F33C013726D@apple.com>
	<199d10ce0912230100me78cb07i35e9ba66058cbea0@mail.gmail.com>
Message-ID: <7D3C53E5-A3FE-4BF6-8338-5D28A21B6114@apple.com>


On Dec 23, 2009, at 1:00 AM, Christian Ad?ker wrote:

> On Wed, Dec 23, 2009 at 12:13 AM, Chris Lattner <clattner at apple.com>  
> wrote:
>> A nice cleanup in that code would be to switch it to produce  
>> diagnostics for
>> the error cases instead of using printf, would you be interested in  
>> tackling
>> that too?
>
> Sure. I also took the liberty of updating a few comments and the TODO.

Very nice, thanks!
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20091221/025781.html

-Chris

From gwk.lists at gmail.com  Wed Dec 23 14:06:11 2009
From: gwk.lists at gmail.com (George King)
Date: Wed, 23 Dec 2009 12:06:11 -0800
Subject: [cfe-dev] make update not updating clang svn?
In-Reply-To: <4B322099.7090601@gmail.com>
References: <BE309558-D029-463B-8D1C-AB3F4C0857DC@gmail.com>
	<557D8988-A3B0-48C7-9F93-F674C46FB4FE@apple.com>
	<4B322099.7090601@gmail.com>
Message-ID: <4243307C-F01A-49D9-B448-A1D6674D6D4D@gmail.com>

>>> 'make update' did not appear to run 'svn update' for the tools/clang
>>> directory.

> Sometime ago I tracked that problem down to svn info... But now I tried to reproduce and make update worked... Weird.

I took a look at the llvm Makefile.  Here is the relevant part:

SVN = svn
SVN-UPDATE-OPTIONS =
AWK = awk
SUB-SVN-DIRS = $(AWK) '/\?\ \ \ \ \ \ / {print $$2}'   \
		| LC_ALL=C xargs $(SVN) info 2>/dev/null \
		| $(AWK) '/Path:\ / {print $$2}'

update:
	$(SVN) $(SVN-UPDATE-OPTIONS) update $(LLVM_SRC_ROOT)
	@ $(SVN) status $(LLVM_SRC_ROOT) | $(SUB-SVN-DIRS) | xargs $(SVN) $(SVN-UPDATE-OPTIONS) update


My understanding of this pipeline is as follows:
  run 'svn status' on llvm
  for every line that matches something in awk,
  run 'svn info'
  pull out the path value with awk
  run 'svn update' on that
 
When I run 'svn status' I get no output, so the rest of the chain does nothing. This explains why it works for the clang developers most of the time: any time you make a local change, then the clang directory gets picked up.

This all seems a bit complicated for the task at hand. The least confusing solution is to just list the sub repositories; how many sub repositories are there? considering that clang is mentioned explicitly in other parts of the makefile, this seems reasonable. Pasted below is a diff to Makefile.

Otherwise, I think the initial 'svn status' should be changed to something along the lines of:

 find $(LLVM_SRC_ROOT) -type d  -maxdepth 2 ! -regex '.*/\...*' 

The regex at the end excludes hidden directories like .svn. I tried svn ls -R, and it was painfully slow. Unfortunately, find does not completely work either. The following bit yields duplicate paths, and then bombs out on the Debug/lib directory:
find . -type d -maxdepth 2 ! -regex '.*/\..*' | xargs svn info

Hope this helps,

george


Index: Makefile
===================================================================
--- Makefile	(revision 92033)
+++ Makefile	(working copy)
@@ -207,14 +207,10 @@
 
 SVN = svn
 SVN-UPDATE-OPTIONS =
-AWK = awk
-SUB-SVN-DIRS = $(AWK) '/\?\ \ \ \ \ \ / {print $$2}'   \
-		| LC_ALL=C xargs $(SVN) info 2>/dev/null \
-		| $(AWK) '/Path:\ / {print $$2}'
 
 update:
 	$(SVN) $(SVN-UPDATE-OPTIONS) update $(LLVM_SRC_ROOT)
-	@ $(SVN) status $(LLVM_SRC_ROOT) | $(SUB-SVN-DIRS) | xargs $(SVN) $(SVN-UPDATE-OPTIONS) update
+	$(SVN) $(SVN-UPDATE-OPTIONS) update $(LLVM_SRC_ROOT)/tools/clang
 
 happiness: update all check unittests
 



From mtzrgb at gmail.com  Wed Dec 23 17:31:40 2009
From: mtzrgb at gmail.com (moataz ragab)
Date: Thu, 24 Dec 2009 01:31:40 +0200
Subject: [cfe-dev] linking external components to clang
In-Reply-To: <6dcf3dab0912221501l60ddd4edid0f376c700b86f1@mail.gmail.com>
References: <6dcf3dab0912221501l60ddd4edid0f376c700b86f1@mail.gmail.com>
Message-ID: <6dcf3dab0912231531x2a838919q12d0986c6c76e5f1@mail.gmail.com>

Hi I found this out.
I have to add the library to USEDLIBS and for now put the library under
Debug/lib

Best regards,
Moataz

On Wed, Dec 23, 2009 at 1:01 AM, moataz ragab <mtzrgb at gmail.com> wrote:

> Hi,
>
> I would like to link non-clang, non-llvm library to my modified version of
> clang.  I can't easily find which variable to add to the make file to get it
> linked using the default llvm/clang build.
>
> Thanks,
> Moataz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091224/745bd806/attachment.html 

From pushkar.ratnalikar at gmail.com  Wed Dec 23 17:40:54 2009
From: pushkar.ratnalikar at gmail.com (Pushkar Ratnalikar)
Date: Wed, 23 Dec 2009 18:40:54 -0500
Subject: [cfe-dev] Error using example plugin
Message-ID: <27e21cc40912231540v30c010aay96391c6dfa8806c8@mail.gmail.com>

Hello All,

I am relatively new to clang. I recently downloaded the latest code from the
subversion repository and tried to compile and use the plugin in the
examples directory. I followed the instructions in the README file and
rebuilt clang by disabling the TOOL_NO_EXPORT.

I am able to generate the libPrintFunctionNames.so file. But when I try to
use it, I get the error "unable to find plugin 'print-fns'"

I am invoking it using "$ clang -cc1 -load LLVM/llvm-2.6/Release/lib -plugin
print-fns trial.c"

libPrintfunctionNames is in LLVM/llvm-2.6/Release/lib


The source file "trial.c" has the following code
====================================
#include <stdio.h>

int f();
int g();
int main(int argc, char** argv)
{
    int x,y,z;
    x=10;
    y=20;
    z=x+y;
    printf("Hello World %d\n",z);
    return 0;
}
=====================================


Am I missing something?

Thanks in advance !

Regards,
Pushkar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091223/26a8e118/attachment.html 

From kremenek at apple.com  Wed Dec 23 19:08:28 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Wed, 23 Dec 2009 17:08:28 -0800
Subject: [cfe-dev] why does ForStmt have a CondVar field?
Message-ID: <9BDC17D6-C879-4FFC-98BC-00897F3F951D@apple.com>

I noticed that ForStmt has a CondVar field, similar to the condition variable field for IfStmt and WhileStmt.  Unlike these other Stms, however, ForStmt uses a DeclStmt for the initialization expression.  From what I can tell, the CondVar field in ForStmt is always NULL.

Is it needed?  It also doesn't make semantic sense, since there is no notion of one condition variable, as one can declare multiple variables in the initialization of the ForStmt.

From eli.friedman at gmail.com  Wed Dec 23 19:21:08 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 23 Dec 2009 17:21:08 -0800
Subject: [cfe-dev] why does ForStmt have a CondVar field?
In-Reply-To: <9BDC17D6-C879-4FFC-98BC-00897F3F951D@apple.com>
References: <9BDC17D6-C879-4FFC-98BC-00897F3F951D@apple.com>
Message-ID: <f5aa3e9b0912231721n2f86f1cbub06e16b6daa5cefb@mail.gmail.com>

On Wed, Dec 23, 2009 at 5:08 PM, Ted Kremenek <kremenek at apple.com> wrote:
> I noticed that ForStmt has a CondVar field, similar to the condition variable field for IfStmt and WhileStmt. ?Unlike these other Stms, however, ForStmt uses a DeclStmt for the initialization expression. ?From what I can tell, the CondVar field in ForStmt is always NULL.
>
> Is it needed? ?It also doesn't make semantic sense, since there is no notion of one condition variable, as one can declare multiple variables in the initialization of the ForStmt.

void a() { for (int x = 0;int y = x;x++) {} }

-Eli


From kremenek at apple.com  Wed Dec 23 19:50:06 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Wed, 23 Dec 2009 17:50:06 -0800
Subject: [cfe-dev] why does ForStmt have a CondVar field?
In-Reply-To: <f5aa3e9b0912231721n2f86f1cbub06e16b6daa5cefb@mail.gmail.com>
References: <9BDC17D6-C879-4FFC-98BC-00897F3F951D@apple.com>
	<f5aa3e9b0912231721n2f86f1cbub06e16b6daa5cefb@mail.gmail.com>
Message-ID: <8D7910E8-ACAD-4102-BC81-03A272955C8B@apple.com>


On Dec 23, 2009, at 5:21 PM, Eli Friedman wrote:

> On Wed, Dec 23, 2009 at 5:08 PM, Ted Kremenek <kremenek at apple.com> wrote:
>> I noticed that ForStmt has a CondVar field, similar to the condition variable field for IfStmt and WhileStmt.  Unlike these other Stms, however, ForStmt uses a DeclStmt for the initialization expression.  From what I can tell, the CondVar field in ForStmt is always NULL.
>> 
>> Is it needed?  It also doesn't make semantic sense, since there is no notion of one condition variable, as one can declare multiple variables in the initialization of the ForStmt.
> 
> void a() { for (int x = 0;int y = x;x++) {} }
> 
> -Eli

Right, thanks Eli.

From wan at google.com  Wed Dec 23 23:43:57 2009
From: wan at google.com (=?UTF-8?B?WmhhbnlvbmcgV2FuICjOu3gueCB4KQ==?=)
Date: Wed, 23 Dec 2009 21:43:57 -0800
Subject: [cfe-dev] numbered warnings & errors?
Message-ID: <89adf3280912232143j32007f91tf1a52bf4a6ac6cdc@mail.gmail.com>

Hi,

Sorry if this has been discussed before.  What do people say to
assigning each warning/error a number and printing that number as part
of the compiler message, like what MSVC does?

When we see a compiler error/warning, often we need to read up on what
it really means.  A unique number is much easier to search for than
the actual message, which can change from one version of Clang to
another.  Also different warnings/errors may have similar messages,
making a search even harder.

Unique error/warning numbers also make it easier to suppress warnings
using -W or #pragma.  When I see a warning message, I can suppress it
using the warning number in it.  I don't have to look up the symbolic
ID of the warning from the Clang documentation.  (While this problem
can be solved by printing the symbolic ID as part of the message, it's
visually more intrusive.)

Thoughts?  Thanks,

-- 
Zhanyong

From chandlerc at google.com  Wed Dec 23 23:54:20 2009
From: chandlerc at google.com (Chandler Carruth)
Date: Wed, 23 Dec 2009 21:54:20 -0800
Subject: [cfe-dev] numbered warnings & errors?
In-Reply-To: <89adf3280912232143j32007f91tf1a52bf4a6ac6cdc@mail.gmail.com>
References: <89adf3280912232143j32007f91tf1a52bf4a6ac6cdc@mail.gmail.com>
Message-ID: <74c447500912232154n4c920927y792c5a664aa63704@mail.gmail.com>

On Wed, Dec 23, 2009 at 9:43 PM, Zhanyong Wan (?x.x x) <wan at google.com> wrote:
> Hi,
>
> Sorry if this has been discussed before. ?What do people say to
> assigning each warning/error a number and printing that number as part
> of the compiler message, like what MSVC does?
>
> When we see a compiler error/warning, often we need to read up on what
> it really means. ?A unique number is much easier to search for than
> the actual message, which can change from one version of Clang to
> another. ?Also different warnings/errors may have similar messages,
> making a search even harder.
>
> Unique error/warning numbers also make it easier to suppress warnings
> using -W or #pragma. ?When I see a warning message, I can suppress it
> using the warning number in it. ?I don't have to look up the symbolic
> ID of the warning from the Clang documentation. ?(While this problem
> can be solved by printing the symbolic ID as part of the message, it's
> visually more intrusive.)

Personally, I'd accept the intrusion to have something easier than a
number to refer to. It should be equally searchable. But I do agree
with printing some identifier, whatever form it takes.

>
> Thoughts? ?Thanks,
>
> --
> Zhanyong
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From ioripolo at gmail.com  Thu Dec 24 00:31:45 2009
From: ioripolo at gmail.com (=?GB2312?B?1cLA2g==?=)
Date: Thu, 24 Dec 2009 14:31:45 +0800
Subject: [cfe-dev] Compile errors on MSVC
Message-ID: <aa9a5e500912232231y7bbf3748ia5144db52ae01e4d@mail.gmail.com>

The latest version of clang has many explicit calls to the destructor of
Class Stmt. These produce some compile errors in MSVC.

something like this:

1>.\Stmt.cpp(112) : error C2300: 'clang::SwitchStmt' : class does not have a
destructor called '~Stmt'
1>.\Stmt.cpp(476) : error C2300: 'clang::IfStmt' : class does not have a
destructor called '~Stmt'
1>.\Stmt.cpp(501) : error C2300: 'clang::WhileStmt' : class does not have a
destructor called '~Stmt'

I don't know how to do with this. Can someone fix it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091224/a3e8c5ee/attachment.html 

From daniel at zuster.org  Thu Dec 24 02:09:00 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 24 Dec 2009 00:09:00 -0800
Subject: [cfe-dev] numbered warnings & errors?
In-Reply-To: <74c447500912232154n4c920927y792c5a664aa63704@mail.gmail.com>
References: <89adf3280912232143j32007f91tf1a52bf4a6ac6cdc@mail.gmail.com>
	<74c447500912232154n4c920927y792c5a664aa63704@mail.gmail.com>
Message-ID: <6a8523d60912240009v30934a67h963b11ea77cf2191@mail.gmail.com>

2009/12/23 Chandler Carruth <chandlerc at google.com>:
> On Wed, Dec 23, 2009 at 9:43 PM, Zhanyong Wan (?x.x x) <wan at google.com> wrote:
>> Hi,
>>
>> Sorry if this has been discussed before. ?What do people say to
>> assigning each warning/error a number and printing that number as part
>> of the compiler message, like what MSVC does?
>>
>> When we see a compiler error/warning, often we need to read up on what
>> it really means. ?A unique number is much easier to search for than
>> the actual message, which can change from one version of Clang to
>> another. ?Also different warnings/errors may have similar messages,
>> making a search even harder.
>>
>> Unique error/warning numbers also make it easier to suppress warnings
>> using -W or #pragma. ?When I see a warning message, I can suppress it
>> using the warning number in it. ?I don't have to look up the symbolic
>> ID of the warning from the Clang documentation. ?(While this problem
>> can be solved by printing the symbolic ID as part of the message, it's
>> visually more intrusive.)
>
> Personally, I'd accept the intrusion to have something easier than a
> number to refer to. It should be equally searchable. But I do agree
> with printing some identifier, whatever form it takes.

I also found the MSVC warning numbers to be really useful in practice,
but want something better. A proposal I thought about making, but
haven't actually written, was to organize diagnostics into a compact
reverse dotted notation. The idea being that a fully dotted warning
should be easy to google / search docs for, and the components in the
dot could be useful for organization and high level grouping.

I'm not in a particular rush to see this problem solved though,
because a lot of the value of having stable warning numbers/names is
in the stability, so letting our diagnostics bake for a while is good.

I'm also curious about alternate approaches which don't rely on
exposing a stable name to the user (for example, by having the
compiler embed some of the documentation, which could then have a
verbose link to more information -- it would still be keyed by some
number + version, but not in a way that needs to be stable).

 - Daniel

>>
>> Thoughts? ?Thanks,
>>
>> --
>> Zhanyong
>> _______________________________________________
>> 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
>


From dgregor at apple.com  Thu Dec 24 16:09:07 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 24 Dec 2009 14:09:07 -0800
Subject: [cfe-dev] Clang Builds LLVM
Message-ID: <8B970E8C-1C20-43FC-A8CE-52150D224D0B@apple.com>

Just in time for the Christmas holiday, the Clang project has hit a major milestone: Clang can now build all of LLVM and Clang [*]!

More information available at:

	http://blog.llvm.org/2009/12/clang-builds-llvm.html

Congratulations to everyone involved in the development of Clang on hitting this milestone. Let's keep up the momentum to make Clang the best C/C++/Objective-C compiler around!

	- Doug

[*] Hint: you don't want to use the Clang-built-Clang yet :)



From jason.haslam at gmail.com  Thu Dec 24 16:33:37 2009
From: jason.haslam at gmail.com (Jason Haslam)
Date: Thu, 24 Dec 2009 15:33:37 -0700
Subject: [cfe-dev] Compile .c file with clang++?
Message-ID: <5E265764-9602-4EA6-A5A7-419F33712A82@gmail.com>

Hello,

I expected to be able to compile a .c file in C++ mode by using the clang++ symlink.  Instead it seems to prefer the .c extension and compile as C.  Is this by design?  Thanks,

Jason

From daniel at zuster.org  Thu Dec 24 16:58:05 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 24 Dec 2009 14:58:05 -0800
Subject: [cfe-dev] Compile .c file with clang++?
In-Reply-To: <5E265764-9602-4EA6-A5A7-419F33712A82@gmail.com>
References: <5E265764-9602-4EA6-A5A7-419F33712A82@gmail.com>
Message-ID: <6a8523d60912241458r11aa5106q70188fdcc9df1e9d@mail.gmail.com>

On Thu, Dec 24, 2009 at 2:33 PM, Jason Haslam <jason.haslam at gmail.com> wrote:
> Hello,
>
> I expected to be able to compile a .c file in C++ mode by using the clang++ symlink. ?Instead it seems to prefer the .c extension and compile as C. ?Is this by design? ?Thanks,

No, it's a bug. We have a bugzilla on it, although I don't have the # handy.

 - Daniel

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


From jon at ffconsultancy.com  Thu Dec 24 18:29:41 2009
From: jon at ffconsultancy.com (Jon Harrop)
Date: Fri, 25 Dec 2009 00:29:41 +0000
Subject: [cfe-dev] Clang Builds LLVM
In-Reply-To: <8B970E8C-1C20-43FC-A8CE-52150D224D0B@apple.com>
References: <8B970E8C-1C20-43FC-A8CE-52150D224D0B@apple.com>
Message-ID: <200912250029.41621.jon@ffconsultancy.com>

On Thursday 24 December 2009 22:09:07 Douglas Gregor wrote:
> Just in time for the Christmas holiday, the Clang project has hit a major
> milestone: Clang can now build all of LLVM and Clang [*]!

That's absolutely incredible. Well done!

Merry Christmas,
-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

From jason.haslam at gmail.com  Thu Dec 24 17:24:20 2009
From: jason.haslam at gmail.com (Jason Haslam)
Date: Thu, 24 Dec 2009 16:24:20 -0700
Subject: [cfe-dev] Compile .c file with clang++?
In-Reply-To: <6a8523d60912241458r11aa5106q70188fdcc9df1e9d@mail.gmail.com>
References: <5E265764-9602-4EA6-A5A7-419F33712A82@gmail.com>
	<6a8523d60912241458r11aa5106q70188fdcc9df1e9d@mail.gmail.com>
Message-ID: <3E0F6505-E404-43A8-AAF4-DCECEA9C9B7E@gmail.com>

Okay, thanks!  I was going to submit a bug report but thought I had better ask here first.

Jason


On Dec 24, 2009, at 3:58 PM, Daniel Dunbar wrote:

> On Thu, Dec 24, 2009 at 2:33 PM, Jason Haslam <jason.haslam at gmail.com> wrote:
>> Hello,
>> 
>> I expected to be able to compile a .c file in C++ mode by using the clang++ symlink.  Instead it seems to prefer the .c extension and compile as C.  Is this by design?  Thanks,
> 
> No, it's a bug. We have a bugzilla on it, although I don't have the # handy.
> 
> - Daniel
> 
>> 
>> Jason
>> _______________________________________________
>> 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 Dec 24 19:09:08 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 24 Dec 2009 17:09:08 -0800
Subject: [cfe-dev] Clang Builds LLVM
In-Reply-To: <8B970E8C-1C20-43FC-A8CE-52150D224D0B@apple.com>
References: <8B970E8C-1C20-43FC-A8CE-52150D224D0B@apple.com>
Message-ID: <E9843350-946F-4DF7-BE05-2B303CCD8595@apple.com>

Awesome!!  Congrats to everyone who worked on it!

-Chris

On Dec 24, 2009, at 2:09 PM, Douglas Gregor <dgregor at apple.com> wrote:

> Just in time for the Christmas holiday, the Clang project has hit a  
> major milestone: Clang can now build all of LLVM and Clang [*]!
>
> More information available at:
>
>    http://blog.llvm.org/2009/12/clang-builds-llvm.html
>
> Congratulations to everyone involved in the development of Clang on  
> hitting this milestone. Let's keep up the momentum to make Clang the  
> best C/C++/Objective-C compiler around!
>
>    - Doug
>
> [*] Hint: you don't want to use the Clang-built-Clang yet :)
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

From rjmccall at apple.com  Thu Dec 24 19:11:52 2009
From: rjmccall at apple.com (John McCall)
Date: Thu, 24 Dec 2009 17:11:52 -0800
Subject: [cfe-dev] -Wsign-compare results on LLVM/clang
Message-ID: <DD77F8C4-4699-4E76-B533-4F9A7A913BC3@apple.com>

I've made an audit of the -Wsign-compare warnings that clang is emitting on LLVM/Clang.  And here it is!

lib/CodeGen/SelectionDAG/DAGCombiner.cpp:5382:37: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

  This is legitimate; AFAICT there's an actual bug here where the code uses -1 as a sentinel value and then that gets converted to unsigned and potentially used in arithmetic.

lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:189:55: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

      unsigned NumParts;
      ...
      unsigned RoundParts = NumParts & (NumParts - 1) ?
        1 << Log2_32(NumParts) : NumParts;

  False positive.  clang can avoid this warning by not diagnosing if the left operand is a bitshift of a literal.

include/llvm/CodeGen/MachORelocation.h:44:54: warning: operands of ? are integers of different signs: 'int32_t const' (aka 'int const') and 'uint32_t const' (aka 'unsigned int const') [-Wsign-compare]

    uint32_t getAddress() const { return r_scattered ? r_value : r_address; }

  If this is noise it's good noise.  Can r_value ever be negative?  If not, why is it signed?

lib/Target/X86/X86FastISel.cpp:306:45: warning: operands of ? are integers of different signs: 'int64_t' (aka 'long long') and 'uint64_t' (aka 'unsigned long long') [-Wsign-compare]

      addFullAddress(BuildMI(MBB, DL, TII.get(Opc)), AM)
                             .addImm(Signed ? CI->getSExtValue() :
                                              CI->getZExtValue());

  False positive because addImm just cares about its operand as a bit-pattern.  Damned if I know how to avoid diagnosing this.

lib/Target/MSP430/AsmPrinter/MSP430AsmPrinter.cpp:127:49: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

      O << ',' << (MAI->getAlignmentIsInBytes() ? (1 << Align) : Align);

  False positive, same resolution as earlier.

lib/Target/X86/X86ISelLowering.cpp:3245:22: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]

    int Val = isLeft ? (i - NumZeros) : i;

  False positive.  Could easily be worked around by using unsigned instead of int.

lib/Target/X86/X86ISelLowering.cpp:3246:39: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

    int Idx = SVOp->getMaskElt(isLeft ? i : (i - NumZeros));

  Same thing.

lib/Target/ARM/ARMLoadStoreOptimizer.cpp:793:5: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]

  int Offset = isAM2
    ? ARM_AM::getAM2Offset(OffField)
    : (isAM3 ? ARM_AM::getAM3Offset(OffField)
             : ARM_AM::getAM5Offset(OffField) * 4);

  Might be a false positive; probably worth complaining about, though.

lib/Target/SystemZ/SystemZRegisterInfo.cpp:203:44: warning: operands of ? are integers of different signs: 'int64_t' (aka 'long long') and 'uint64_t' (aka 'unsigned long long') [-Wsign-compare]

    uint64_t ThisVal = (Offset > Chunk) ? Chunk : Offset;
    ...                                                   
      .addReg(SystemZ::R15D).addImm((isSub ? -(int64_t)ThisVal : ThisVal));

  False positive, addImm just wants a bit-pattern.  No idea how to avoid warning about this while still being useful.

lib/Target/SystemZ/AsmPrinter/SystemZAsmPrinter.cpp:340:49: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

      O << ',' << (MAI->getAlignmentIsInBytes() ? (1 << Align) : Align);

  False positive, will be fixed.

lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp:1254:55: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

            O << ',' << (MAI->getAlignmentIsInBytes() ? (1 << Align) : Align);

  False positive, will be fixed.

lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp:1261:53: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

          O << "," << (MAI->getAlignmentIsInBytes() ? (1 << Align) : Align);

  False positive, will be fixed.

lib/Target/X86/AsmPrinter/X86AsmPrinter.cpp:734:55: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
lib/Target/X86/AsmPrinter/X86AsmPrinter.cpp:743:53: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

  I need to look into these.

lib/CodeGen/VirtRegRewriter.cpp:870:11: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]

        int SSorRMId = DoReMat
          ? VRM.getReMatId(NewOp.VirtReg) : NewOp.StackSlotOrReMat;

  False positive, I think.

tools/clang/lib/Basic/SourceManager.cpp:46:17: warning: operands of ? are integers of different signs: 'size_t' (aka 'unsigned long') and 'off_t' (aka 'long long') [-Wsign-compare]

  return Buffer ? Buffer->getBufferSize() : Entry->getSize();

  False positive: getBufferSize() is always positive.  It's possible this could be suppressed by noting that the signed operand is of higher rank than the unsigned operand, even though they're the same size.  I need to look into whether that will bury too many actual problems.

tools/clang/lib/Driver/ArgList.cpp:83:18: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
tools/clang/lib/Driver/ArgList.cpp:84:18: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
tools/clang/lib/Driver/ArgList.cpp:85:18: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]

  int A0Idx = A0 ? A0->getIndex() : -1;
  int A1Idx = A1 ? A1->getIndex() : -1;
  int A2Idx = A2 ? A2->getIndex() : -1;

  These are false positives (assuming fewer than 2^31 arguments) because of the implicit conversion back to signed int.  I don't really have a problem with warning about them, though.

tools/clang/lib/Analysis/CheckSecuritySyntaxOnly.cpp:456:25: warning: comparison of integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]

  The only diagnostic arising from comparisons rather than the conditional operator.  This is a false positive which I can fix pretty easily.

John.

From xuzhongxing at gmail.com  Thu Dec 24 19:13:09 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Fri, 25 Dec 2009 09:13:09 +0800
Subject: [cfe-dev] Clang Builds LLVM
In-Reply-To: <8B970E8C-1C20-43FC-A8CE-52150D224D0B@apple.com>
References: <8B970E8C-1C20-43FC-A8CE-52150D224D0B@apple.com>
Message-ID: <5400aeb80912241713l792c376fw7b32d2c8545556c0@mail.gmail.com>

Amazing!

2009/12/25 Douglas Gregor <dgregor at apple.com>

> Just in time for the Christmas holiday, the Clang project has hit a major
> milestone: Clang can now build all of LLVM and Clang [*]!
>
> More information available at:
>
>        http://blog.llvm.org/2009/12/clang-builds-llvm.html
>
> Congratulations to everyone involved in the development of Clang on hitting
> this milestone. Let's keep up the momentum to make Clang the best
> C/C++/Objective-C compiler around!
>
>        - Doug
>
> [*] Hint: you don't want to use the Clang-built-Clang yet :)
>
>
> _______________________________________________
> 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/20091225/8fefa37f/attachment-0001.html 

From joe at alacatialabs.com  Thu Dec 24 19:29:31 2009
From: joe at alacatialabs.com (Joe Ranieri)
Date: Thu, 24 Dec 2009 20:29:31 -0500
Subject: [cfe-dev] Getting Started
Message-ID: <4B34157B.7090300@alacatialabs.com>

Hi, is there any documentation on getting started using the Clang 
libraries in a project? A few months back, I had it working with the 
code below, but it has since broken. I looked a bit and it's non-obvious 
how to do this correctly (I simply want to run an ASTConsumer over a 
source file).

-- Joe Ranieri


TextDiagnosticBuffer diagClient;
Diagnostic diags(&diagClient);
LangOptions opts;
opts.ObjC1 = true;
opts.ObjC2 = true;
opts.ObjCNonFragileABI = true;
opts.Blocks = true;

FileManager fm;
SourceManager sm;
HeaderSearch headers(fm);
InitHeaderSearch init(headers);
init.AddDefaultSystemIncludePaths(opts);
init.Realize();

const FileEntry* file = fm.getFile(argv[1]);
sm.createMainFileID(file, SourceLocation());

OwningPtr<TargetInfo> target(TargetInfo::CreateTargetInfo(LLVM_HOSTTRIPLE));
Preprocessor pp(diags, opts, *target, sm, headers);
ASTContext context(pp.getLangOptions(),
				   pp.getSourceManager(),
				   pp.getTargetInfo(),
				   pp.getIdentifierTable(),
				   pp.getSelectorTable(),
				   pp.getBuiltinInfo());

TestConsumer consumer;
ParseAST(pp, &consumer, context, false);

From rengolin at systemcall.org  Fri Dec 25 05:28:56 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Fri, 25 Dec 2009 11:28:56 +0000
Subject: [cfe-dev] numbered warnings & errors?
In-Reply-To: <6a8523d60912240009v30934a67h963b11ea77cf2191@mail.gmail.com>
References: <89adf3280912232143j32007f91tf1a52bf4a6ac6cdc@mail.gmail.com>
	<74c447500912232154n4c920927y792c5a664aa63704@mail.gmail.com>
	<6a8523d60912240009v30934a67h963b11ea77cf2191@mail.gmail.com>
Message-ID: <d9b9d95f0912250328x6d297073i5f2c2d274bd130ee@mail.gmail.com>

2009/12/24 Daniel Dunbar <daniel at zuster.org>:
> I'm also curious about alternate approaches which don't rely on
> exposing a stable name to the user (for example, by having the
> compiler embed some of the documentation, which could then have a
> verbose link to more information -- it would still be keyed by some
> number + version, but not in a way that needs to be stable).

Hi Daniel.

I've used codes to determine error traces as well, when one condition
caused the other. So, for instance, if you have a tokenizer error
causing a parser error, or a lexical or syntax error, you can trace
what's really going on. A header with the error codes could make it
easier to google for it, too.

ERROR: Sema21-Tok12 (semantic analysis failed because tokenizer got EOF)

The problem with context help is that, especially in compilers, there
could be multiple causes to a specific problem and each could have
multiple fixes. Printing them out on the console would clutter a lot,
not to mention formatting that text...

Maybe, if the console supports hypertext (more likely on IDEs), you
could embed links and put the documentation online. When it's not
supported, you could print small hashes that would be redirected to
the right page when the user puts in their browsers
(firefox+google-feeling-lucky would do the trick).

cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From daniel at zuster.org  Fri Dec 25 11:46:24 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 25 Dec 2009 09:46:24 -0800
Subject: [cfe-dev] -Wsign-compare results on LLVM/clang
In-Reply-To: <DD77F8C4-4699-4E76-B533-4F9A7A913BC3@apple.com>
References: <DD77F8C4-4699-4E76-B533-4F9A7A913BC3@apple.com>
Message-ID: <6a8523d60912250946x1a0d6798l8499a83df13fb094@mail.gmail.com>

Meta question, what rule is gcc following that we don't get these
warnings with it?

 - Daniel

On Thu, Dec 24, 2009 at 5:11 PM, John McCall <rjmccall at apple.com> wrote:
> I've made an audit of the -Wsign-compare warnings that clang is emitting on LLVM/Clang. ?And here it is!
>
> lib/CodeGen/SelectionDAG/DAGCombiner.cpp:5382:37: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ?This is legitimate; AFAICT there's an actual bug here where the code uses -1 as a sentinel value and then that gets converted to unsigned and potentially used in arithmetic.
>
> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:189:55: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ? ? ?unsigned NumParts;
> ? ? ?...
> ? ? ?unsigned RoundParts = NumParts & (NumParts - 1) ?
> ? ? ? ?1 << Log2_32(NumParts) : NumParts;
>
> ?False positive. ?clang can avoid this warning by not diagnosing if the left operand is a bitshift of a literal.
>
> include/llvm/CodeGen/MachORelocation.h:44:54: warning: operands of ? are integers of different signs: 'int32_t const' (aka 'int const') and 'uint32_t const' (aka 'unsigned int const') [-Wsign-compare]
>
> ? ?uint32_t getAddress() const { return r_scattered ? r_value : r_address; }
>
> ?If this is noise it's good noise. ?Can r_value ever be negative? ?If not, why is it signed?
>
> lib/Target/X86/X86FastISel.cpp:306:45: warning: operands of ? are integers of different signs: 'int64_t' (aka 'long long') and 'uint64_t' (aka 'unsigned long long') [-Wsign-compare]
>
> ? ? ?addFullAddress(BuildMI(MBB, DL, TII.get(Opc)), AM)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .addImm(Signed ? CI->getSExtValue() :
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?CI->getZExtValue());
>
> ?False positive because addImm just cares about its operand as a bit-pattern. ?Damned if I know how to avoid diagnosing this.
>
> lib/Target/MSP430/AsmPrinter/MSP430AsmPrinter.cpp:127:49: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ? ? ?O << ',' << (MAI->getAlignmentIsInBytes() ? (1 << Align) : Align);
>
> ?False positive, same resolution as earlier.
>
> lib/Target/X86/X86ISelLowering.cpp:3245:22: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
>
> ? ?int Val = isLeft ? (i - NumZeros) : i;
>
> ?False positive. ?Could easily be worked around by using unsigned instead of int.
>
> lib/Target/X86/X86ISelLowering.cpp:3246:39: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ? ?int Idx = SVOp->getMaskElt(isLeft ? i : (i - NumZeros));
>
> ?Same thing.
>
> lib/Target/ARM/ARMLoadStoreOptimizer.cpp:793:5: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
>
> ?int Offset = isAM2
> ? ?? ARM_AM::getAM2Offset(OffField)
> ? ?: (isAM3 ? ARM_AM::getAM3Offset(OffField)
> ? ? ? ? ? ? : ARM_AM::getAM5Offset(OffField) * 4);
>
> ?Might be a false positive; probably worth complaining about, though.
>
> lib/Target/SystemZ/SystemZRegisterInfo.cpp:203:44: warning: operands of ? are integers of different signs: 'int64_t' (aka 'long long') and 'uint64_t' (aka 'unsigned long long') [-Wsign-compare]
>
> ? ?uint64_t ThisVal = (Offset > Chunk) ? Chunk : Offset;
> ? ?...
> ? ? ?.addReg(SystemZ::R15D).addImm((isSub ? -(int64_t)ThisVal : ThisVal));
>
> ?False positive, addImm just wants a bit-pattern. ?No idea how to avoid warning about this while still being useful.
>
> lib/Target/SystemZ/AsmPrinter/SystemZAsmPrinter.cpp:340:49: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ? ? ?O << ',' << (MAI->getAlignmentIsInBytes() ? (1 << Align) : Align);
>
> ?False positive, will be fixed.
>
> lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp:1254:55: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ? ? ? ? ? ?O << ',' << (MAI->getAlignmentIsInBytes() ? (1 << Align) : Align);
>
> ?False positive, will be fixed.
>
> lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp:1261:53: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ? ? ? ? ?O << "," << (MAI->getAlignmentIsInBytes() ? (1 << Align) : Align);
>
> ?False positive, will be fixed.
>
> lib/Target/X86/AsmPrinter/X86AsmPrinter.cpp:734:55: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
> lib/Target/X86/AsmPrinter/X86AsmPrinter.cpp:743:53: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ?I need to look into these.
>
> lib/CodeGen/VirtRegRewriter.cpp:870:11: warning: operands of ? are integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>
> ? ? ? ?int SSorRMId = DoReMat
> ? ? ? ? ?? VRM.getReMatId(NewOp.VirtReg) : NewOp.StackSlotOrReMat;
>
> ?False positive, I think.
>
> tools/clang/lib/Basic/SourceManager.cpp:46:17: warning: operands of ? are integers of different signs: 'size_t' (aka 'unsigned long') and 'off_t' (aka 'long long') [-Wsign-compare]
>
> ?return Buffer ? Buffer->getBufferSize() : Entry->getSize();
>
> ?False positive: getBufferSize() is always positive. ?It's possible this could be suppressed by noting that the signed operand is of higher rank than the unsigned operand, even though they're the same size. ?I need to look into whether that will bury too many actual problems.
>
> tools/clang/lib/Driver/ArgList.cpp:83:18: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
> tools/clang/lib/Driver/ArgList.cpp:84:18: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
> tools/clang/lib/Driver/ArgList.cpp:85:18: warning: operands of ? are integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
>
> ?int A0Idx = A0 ? A0->getIndex() : -1;
> ?int A1Idx = A1 ? A1->getIndex() : -1;
> ?int A2Idx = A2 ? A2->getIndex() : -1;
>
> ?These are false positives (assuming fewer than 2^31 arguments) because of the implicit conversion back to signed int. ?I don't really have a problem with warning about them, though.
>
> tools/clang/lib/Analysis/CheckSecuritySyntaxOnly.cpp:456:25: warning: comparison of integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
>
> ?The only diagnostic arising from comparisons rather than the conditional operator. ?This is a false positive which I can fix pretty easily.
>
> John.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From abramobagnara at tin.it  Sat Dec 26 05:06:02 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Sat, 26 Dec 2009 12:06:02 +0100
Subject: [cfe-dev] Huge slowdown introduced in r91449
Message-ID: <4B35EE1A.1000203@tin.it>

Tracking a slowdown observed after a clang update, I've bisected the
problem to commit r91449.

r91448:
$ ~/llvm_opt/Release/bin/clang -w -fsyntax-only gcc.c

real	0m3.683s
user	0m3.354s
sys	0m0.325s

r91449:
$ time ~/llvm_opt/Release/bin/clang -w -fsyntax-only gcc.c

real	0m38.764s
user	0m38.378s
sys	0m0.374s

The very large source file gcc.c (22 MB) is from:

http://people.csail.mit.edu/smcc/projects/single-file-programs/

From abramobagnara at tin.it  Sat Dec 26 09:58:56 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Sat, 26 Dec 2009 16:58:56 +0100
Subject: [cfe-dev] Patch to allow comment translators implementation
Message-ID: <4B3632C0.6040300@tin.it>


This small patch change comments handler in a simple way to permit to
implement quite easily comment translators.

Once applied this patch, a CommentHandler is allowed to build a first
token to be returned to Lexer and to push a TokenStream for the others,
then allowing generic comment -> tokens transformer.

This can be useful to transform comment shaped program annotation that
should be translated to source code and also other interesting applications.

Please let me know if it can be applied as it is or if I can improve it
somehow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HandleComment.patch
Type: text/x-patch
Size: 4824 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091226/303086e6/attachment.bin 

From daniel at zuster.org  Sat Dec 26 13:39:08 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 26 Dec 2009 11:39:08 -0800
Subject: [cfe-dev] Huge slowdown introduced in r91449
In-Reply-To: <4B35EE1A.1000203@tin.it>
References: <4B35EE1A.1000203@tin.it>
Message-ID: <6a8523d60912261139g7f83300flba3561d65acfa136@mail.gmail.com>

Please file a bug report for this, thanks!

 - Daniel

On Sat, Dec 26, 2009 at 3:06 AM, Abramo Bagnara <abramobagnara at tin.it> wrote:
> Tracking a slowdown observed after a clang update, I've bisected the
> problem to commit r91449.
>
> r91448:
> $ ~/llvm_opt/Release/bin/clang -w -fsyntax-only gcc.c
>
> real ? ?0m3.683s
> user ? ?0m3.354s
> sys ? ? 0m0.325s
>
> r91449:
> $ time ~/llvm_opt/Release/bin/clang -w -fsyntax-only gcc.c
>
> real ? ?0m38.764s
> user ? ?0m38.378s
> sys ? ? 0m0.374s
>
> The very large source file gcc.c (22 MB) is from:
>
> http://people.csail.mit.edu/smcc/projects/single-file-programs/
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From abramobagnara at tin.it  Sat Dec 26 13:50:15 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Sat, 26 Dec 2009 20:50:15 +0100
Subject: [cfe-dev] Huge slowdown introduced in r91449
In-Reply-To: <6a8523d60912261139g7f83300flba3561d65acfa136@mail.gmail.com>
References: <4B35EE1A.1000203@tin.it>
	<6a8523d60912261139g7f83300flba3561d65acfa136@mail.gmail.com>
Message-ID: <4B3668F7.4040506@tin.it>

Il 26/12/2009 20:39, Daniel Dunbar ha scritto:
> Please file a bug report for this, thanks!

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

From abramo.bagnara at gmail.com  Sat Dec 26 09:58:14 2009
From: abramo.bagnara at gmail.com (Abramo Bagnara)
Date: Sat, 26 Dec 2009 16:58:14 +0100
Subject: [cfe-dev] Patch to allow comment translators implementation
Message-ID: <4B363296.1010604@gmail.com>


This small patch change comments handler in a simple way to permit to
implement quite easily comment translators.

Once applied this patch, a CommentHandler is allowed to build a first
token to be returned to Lexer and to push a TokenStream for the others,
then allowing generic comment -> tokens transformer.

This can be useful to transform comment shaped program annotation that
should be translated to source code and also other interesting applications.

Please let me know if it can be applied as it is or if I can improve it
somehow.

-- 
Abramo Bagnara

Opera Unica                          Phone: +39.0546.656023
Via Borghesi, 16
48014 Castel Bolognese (RA) - Italy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HandleComment.patch
Type: text/x-patch
Size: 4823 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091226/e50c217a/attachment.bin 

From clattner at apple.com  Tue Dec 29 14:08:35 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 29 Dec 2009 12:08:35 -0800
Subject: [cfe-dev] Patch to allow comment translators implementation
In-Reply-To: <4B3632C0.6040300@tin.it>
References: <4B3632C0.6040300@tin.it>
Message-ID: <04275240-C369-4B7E-ADC0-31DD2E54AF65@apple.com>


On Dec 26, 2009, at 7:58 AM, Abramo Bagnara wrote:

> 
> This small patch change comments handler in a simple way to permit to
> implement quite easily comment translators.
> 
> Once applied this patch, a CommentHandler is allowed to build a first
> token to be returned to Lexer and to push a TokenStream for the others,
> then allowing generic comment -> tokens transformer.
> 
> This can be useful to transform comment shaped program annotation that
> should be translated to source code and also other interesting applications.

This is an interesting approach.  The only major concern I have is that this only allows you to translate comments into exactly one token.  In the case of openmp pragmas (for example) this doesn't seem rich enough.  A different approach would be to allow the handler to push an arbitrary number of tokens into the parser's lookahead buffer.  Would this work for what you're trying to do?

-Chris

From abramobagnara at tin.it  Tue Dec 29 16:51:01 2009
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Tue, 29 Dec 2009 23:51:01 +0100
Subject: [cfe-dev] Patch to allow comment translators implementation
In-Reply-To: <04275240-C369-4B7E-ADC0-31DD2E54AF65@apple.com>
References: <4B3632C0.6040300@tin.it>
	<04275240-C369-4B7E-ADC0-31DD2E54AF65@apple.com>
Message-ID: <4B3A87D5.9000505@tin.it>

Il 29/12/2009 21:08, Chris Lattner ha scritto:
> 
> On Dec 26, 2009, at 7:58 AM, Abramo Bagnara wrote:
> 
>>
>> This small patch change comments handler in a simple way to permit to
>> implement quite easily comment translators.
>>
>> Once applied this patch, a CommentHandler is allowed to build a first
>> token to be returned to Lexer and to push a TokenStream for the others,
>> then allowing generic comment -> tokens transformer.
>>
>> This can be useful to transform comment shaped program annotation that
>> should be translated to source code and also other interesting applications.
> 
> This is an interesting approach.  The only major concern I have is
> that this only allows you to translate comments into exactly one
> token.  In the case of openmp pragmas (for example) this doesn't seem
> rich enough.  A different approach would be to allow the handler to
> push an arbitrary number of tokens into the parser's lookahead
> buffer.  Would this work for what you're trying to do?

Yes, but perhaps this is not needed: as I wrote the CommentHandler could
return a first token *and* produce the other tokens to be read and push
them to lexer stack using EnterTokenStream.

I've already tried this with success in a sample implementation that
simply lex the comment content without modify it:

bool Comment_Converter::HandleComment(clang::Preprocessor &PP,
                                      clang::Token& token,
                                      clang::SourceRange Comment) {
  const clang::SourceManager &sm = PP.getSourceManager();
  const clang::LangOptions &lo = PP.getLangOptions();
  clang::SourceLocation begin = Comment.getBegin();
  clang::FileID fid = sm.getFileID(begin);
  const char* start = sm.getCharacterData(begin);
  const char* end = sm.getCharacterData(Comment.getEnd());
  if (start[1] == '*')
    end -= 2;
  start += 2;
  char saved = *end;
  *const_cast<char*>(end) = 0;
  clang::Lexer lexer(sm.getLocForStartOfFile(fid), lo,
                     sm.getBufferData(fid).first,
                     start, end);
  clang::Token tok;
  lexer.LexFromRawLexer(tok);
  if (tok.is(clang::tok::eof)) {
    *const_cast<char*>(end) = 0;
    return false;
  }
  token = tok;
  static std::vector<clang::Token> tokens;
  tokens.clear();
  while (1) {
    lexer.LexFromRawLexer(tok);
    if (tok.is(clang::tok::eof))
      break;
    if (tok.is(clang::tok::identifier))
      tok.setKind(PP.LookUpIdentifierInfo(tok)->getTokenID());
    tokens.push_back(tok);
  }
  *const_cast<char*>(end) = saved;
  if (tokens.size() > 0)
    PP.EnterTokenStream(tokens.data(), tokens.size(), false, false);
  return true;
}

From Andy.Wick at corp.aol.com  Wed Dec 30 05:44:29 2009
From: Andy.Wick at corp.aol.com (Andy Wick)
Date: Wed, 30 Dec 2009 06:44:29 -0500
Subject: [cfe-dev] C99 VLA bug?
Message-ID: <C760A74D.264B%Andy.Wick@corp.aol.com>

Thanks for all the hard work, I didn?t see this in bugzilla but maybe a
known issue.  The typedef seems to cause the issue, and unfortunately we use
thru out our project.  I?m using svn 92284

The file:
#include <string.h>
typedef unsigned char Byte;
void doit (char *data, int len) {
    if (len) {
        Byte buf[len];
        memcpy(buf, data, len);
    }
}


Compiled with ?clang --analyze t.c?

Gives me:
clang: ASTContext.cpp:2377: clang::QualType
clang::ASTContext::getUnqualifiedArrayType(clang::QualType,
clang::Qualifiers&): Assertion `T.isCanonical() && "Only operates on
canonical types"' failed.
0  clang           0x000000000141b61f
1  clang           0x000000000141be21
2  libpthread.so.0 0x0000002a9567f160
3  libc.so.6       0x0000002a95d5f745 gsignal + 69
4  libc.so.6       0x0000002a95d60eb3 abort + 467
5  libc.so.6       0x0000002a95d58dc9
6  clang           0x000000000084cb06
7  clang           0x000000000084c9ea
8  clang           0x00000000006bc472
9  clang           0x000000000067d86f
10 clang           0x0000000000677124
11 clang           0x000000000067d99b
12 clang           0x0000000000677124
13 clang           0x000000000067608a
14 clang           0x0000000000676fd4
15 clang           0x000000000067dfe1
16 clang           0x000000000066c068
17 clang           0x000000000066c2d2
18 clang           0x00000000004d8b97
19 clang           0x00000000004d7530
20 clang           0x00000000004d7a15
21 clang           0x00000000006e0136
22 clang           0x00000000004345e0
23 clang           0x0000000000437661 main + 1585
24 libc.so.6       0x0000002a95d4d1d7 __libc_start_main + 215
25 clang           0x000000000043246a
Stack dump:
0.    Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name t.c
-analyzer-store=region -analyzer-opt-analyze-nested-blocks -warn-dead-stores
-warn-security-syntactic -checker-cfref -analyzer-eagerly-assume
-warn-objc-methodsigs -warn-objc-unused-ivars -analyzer-output plist
-mrelocation-model static -mdisable-fp-elim -munwind-tables -target-cpu
x86-64 -v -resource-dir /usr/local/lib/clang/1.1 -fmessage-length 138
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o t.plist -x c
t.c 
1.    <eof> parser at end of file
2.    t.c:6:9: Error evaluating statement
3.    t.c:6:9: Error evaluating statement
4.    t.c:6:16: Error evaluating statement
5.    t.c:6:16: Error evaluating statement
clang: error: analyzer command failed due to signal 6 (use -v to see
invocation)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091230/682210c7/attachment.html 

From clattner at apple.com  Wed Dec 30 14:04:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 30 Dec 2009 12:04:45 -0800
Subject: [cfe-dev] C99 VLA bug?
In-Reply-To: <C760A74D.264B%Andy.Wick@corp.aol.com>
References: <C760A74D.264B%Andy.Wick@corp.aol.com>
Message-ID: <C0B39084-7B0F-4708-A376-54BBEAE064EC@apple.com>


On Dec 30, 2009, at 3:44 AM, Andy Wick wrote:

> Thanks for all the hard work, I didn?t see this in bugzilla but maybe a known issue.  The typedef seems to cause the issue, and unfortunately we use thru out our project.  I?m using svn 92284

This looks like a bug in the static analyzer, please file a bugzilla, thanks!

-Chris
 
> 
> The file:
> #include <string.h>
> typedef unsigned char Byte;
> void doit (char *data, int len) {
>     if (len) {
>         Byte buf[len];
>         memcpy(buf, data, len);
>     }
> }
> 
> 
> Compiled with ?clang --analyze t.c?
> 
> Gives me:
> clang: ASTContext.cpp:2377: clang::QualType clang::ASTContext::getUnqualifiedArrayType(clang::QualType, clang::Qualifiers&): Assertion `T.isCanonical() && "Only operates on canonical types"' failed.
> 0  clang           0x000000000141b61f
> 1  clang           0x000000000141be21
> 2  libpthread.so.0 0x0000002a9567f160
> 3  libc.so.6       0x0000002a95d5f745 gsignal + 69
> 4  libc.so.6       0x0000002a95d60eb3 abort + 467
> 5  libc.so.6       0x0000002a95d58dc9
> 6  clang           0x000000000084cb06
> 7  clang           0x000000000084c9ea
> 8  clang           0x00000000006bc472
> 9  clang           0x000000000067d86f
> 10 clang           0x0000000000677124
> 11 clang           0x000000000067d99b
> 12 clang           0x0000000000677124
> 13 clang           0x000000000067608a
> 14 clang           0x0000000000676fd4
> 15 clang           0x000000000067dfe1
> 16 clang           0x000000000066c068
> 17 clang           0x000000000066c2d2
> 18 clang           0x00000000004d8b97
> 19 clang           0x00000000004d7530
> 20 clang           0x00000000004d7a15
> 21 clang           0x00000000006e0136
> 22 clang           0x00000000004345e0
> 23 clang           0x0000000000437661 main + 1585
> 24 libc.so.6       0x0000002a95d4d1d7 __libc_start_main + 215
> 25 clang           0x000000000043246a
> Stack dump:
> 0.    Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name t.c -analyzer-store=region -analyzer-opt-analyze-nested-blocks -warn-dead-stores -warn-security-syntactic -checker-cfref -analyzer-eagerly-assume -warn-objc-methodsigs -warn-objc-unused-ivars -analyzer-output plist -mrelocation-model static -mdisable-fp-elim -munwind-tables -target-cpu x86-64 -v -resource-dir /usr/local/lib/clang/1.1 -fmessage-length 138 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o t.plist -x c t.c 
> 1.    <eof> parser at end of file
> 2.    t.c:6:9: Error evaluating statement
> 3.    t.c:6:9: Error evaluating statement
> 4.    t.c:6:16: Error evaluating statement
> 5.    t.c:6:16: Error evaluating statement
> clang: error: analyzer command failed due to signal 6 (use -v to see invocation)
> _______________________________________________
> 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/20091230/93bad66c/attachment.html 

From xuzhongxing at gmail.com  Wed Dec 30 17:01:38 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Thu, 31 Dec 2009 07:01:38 +0800
Subject: [cfe-dev] C99 VLA bug?
In-Reply-To: <C760A74D.264B%Andy.Wick@corp.aol.com>
References: <C760A74D.264B%Andy.Wick@corp.aol.com>
Message-ID: <5400aeb80912301501q48bf190aiab9d6b2579a418b5@mail.gmail.com>

I committed a tentative fix in r92318. Chris, could you please review it?
Thanks.

2009/12/30 Andy Wick <Andy.Wick at corp.aol.com>

>  Thanks for all the hard work, I didn?t see this in bugzilla but maybe a
> known issue.  The typedef seems to cause the issue, and unfortunately we use
> thru out our project.  I?m using svn 92284
>
> The file:
> #include <string.h>
> typedef unsigned char Byte;
> void doit (char *data, int len) {
>     if (len) {
>         Byte buf[len];
>         memcpy(buf, data, len);
>     }
> }
>
>
> Compiled with ?clang --analyze t.c?
>
> Gives me:
> clang: ASTContext.cpp:2377: clang::QualType
> clang::ASTContext::getUnqualifiedArrayType(clang::QualType,
> clang::Qualifiers&): Assertion `T.isCanonical() && "Only operates on
> canonical types"' failed.
> 0  clang           0x000000000141b61f
> 1  clang           0x000000000141be21
> 2  libpthread.so.0 0x0000002a9567f160
> 3  libc.so.6       0x0000002a95d5f745 gsignal + 69
> 4  libc.so.6       0x0000002a95d60eb3 abort + 467
> 5  libc.so.6       0x0000002a95d58dc9
> 6  clang           0x000000000084cb06
> 7  clang           0x000000000084c9ea
> 8  clang           0x00000000006bc472
> 9  clang           0x000000000067d86f
> 10 clang           0x0000000000677124
> 11 clang           0x000000000067d99b
> 12 clang           0x0000000000677124
> 13 clang           0x000000000067608a
> 14 clang           0x0000000000676fd4
> 15 clang           0x000000000067dfe1
> 16 clang           0x000000000066c068
> 17 clang           0x000000000066c2d2
> 18 clang           0x00000000004d8b97
> 19 clang           0x00000000004d7530
> 20 clang           0x00000000004d7a15
> 21 clang           0x00000000006e0136
> 22 clang           0x00000000004345e0
> 23 clang           0x0000000000437661 main + 1585
> 24 libc.so.6       0x0000002a95d4d1d7 __libc_start_main + 215
> 25 clang           0x000000000043246a
> Stack dump:
> 0.    Program arguments: /usr/local/bin/clang -cc1 -triple
> x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name t.c
> -analyzer-store=region -analyzer-opt-analyze-nested-blocks -warn-dead-stores
> -warn-security-syntactic -checker-cfref -analyzer-eagerly-assume
> -warn-objc-methodsigs -warn-objc-unused-ivars -analyzer-output plist
> -mrelocation-model static -mdisable-fp-elim -munwind-tables -target-cpu
> x86-64 -v -resource-dir /usr/local/lib/clang/1.1 -fmessage-length 138
> -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o t.plist -x c
> t.c
> 1.    <eof> parser at end of file
> 2.    t.c:6:9: Error evaluating statement
> 3.    t.c:6:9: Error evaluating statement
> 4.    t.c:6:16: Error evaluating statement
> 5.    t.c:6:16: Error evaluating statement
> clang: error: analyzer command failed due to signal 6 (use -v to see
> invocation)
>
> _______________________________________________
> 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/20091231/c05baab8/attachment-0001.html 

From cristian.draghici at gmail.com  Thu Dec 31 02:01:37 2009
From: cristian.draghici at gmail.com (Cristian Draghici)
Date: Thu, 31 Dec 2009 10:01:37 +0200
Subject: [cfe-dev] known issue? (using checker-232)
Message-ID: <25cf7a9f0912310001r20c060c0l8dfa53e2063f789b@mail.gmail.com>

Hi

I've bumped into this recently and I can't find on http://llvm.org/bugs/

leak detected:

       NSMutableArray *array = [[NSMutableArray alloc] init];
        [array addObject:@"W"];
        [array addObject:@"W"];

leak not detected when more then two iterations:
        NSMutableArray *array = [[NSMutableArray alloc] init];

        int i=0;
        for(i=0;i<3;i++)
                [array addObject:@"W"];

Is clang looking at a limited number of iterations and deciding defensively
not to signal the leak?

Thanks,
Cristi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091231/6ed8d8e9/attachment.html 

From cristina.basescu at gmail.com  Thu Dec 31 13:29:19 2009
From: cristina.basescu at gmail.com (Cristina Basescu)
Date: Thu, 31 Dec 2009 21:29:19 +0200
Subject: [cfe-dev] file name for Decl
Message-ID: <e3c680380912311129j4bc35108ha22183c93eff065e@mail.gmail.com>

Hi all,

I'm trying to find out the file name where a clang::Decl comes from. More
precisely, I'd like to see which library a certain function comes from e.g.
be able to find out that the definition of printf used in the analyzed
program is in stdio.h. I thought using 'const char *getMangledName(const
GlobalDecl &D)' from CodeGenModule.h could provide some information, however
it seems that CodeGenModule is just used internally and, besides that, one
should not count on the mangled names format.

Any ideas would be appreciated!

Best regards,
Cristina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20091231/d67c610a/attachment.html 

From clattner at apple.com  Thu Dec 31 21:45:14 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 31 Dec 2009 19:45:14 -0800
Subject: [cfe-dev] file name for Decl
In-Reply-To: <e3c680380912311129j4bc35108ha22183c93eff065e@mail.gmail.com>
References: <e3c680380912311129j4bc35108ha22183c93eff065e@mail.gmail.com>
Message-ID: <3CFB554C-28C0-4C8B-859A-B4B1F072E55F@apple.com>


On Dec 31, 2009, at 11:29 AM, Cristina Basescu wrote:

> Hi all,
> 
> I'm trying to find out the file name where a clang::Decl comes from. More precisely, I'd like to see which library a certain function comes from e.g. be able to find out that the definition of printf used in the analyzed program is in stdio.h. I thought using 'const char *getMangledName(const GlobalDecl &D)' from CodeGenModule.h could provide some information, however it seems that CodeGenModule is just used internally and, besides that, one should not count on the mangled names format.

Try getting a source location from the decl.  Given a source location, the SourceManager object can map the location back to a file/line/col for you.

-Chris