[cfe-dev] Matching std::set::iterator
Manuel Klimek
klimek at google.com
Tue Oct 23 04:39:49 PDT 2012
On Tue, Oct 23, 2012 at 1:33 PM, Gábor Horváth <xazax.hun at gmail.com> wrote:
> Hi!
>
> I think there is still no way to get the typedef type of a declaration
> like:
> std::set<int>::iterator it;
>
> It is a ClassTemplateSpecializationDecl, and there is no way to get its
> typedefType. A matchesTypedefName or a similar matcher could solve the
> problem.
>
> There is one more minor thing in the API, and I wonder if it is intended.
>
> There is:
> hasDeclaration matcher for constructExpr, callExpr and QualTypes, and
> there is hasDecl for TypedefTypes. Maybe it would be more consistent to
> call both hasDeclaration?
>
Ah, we probably want to call all of them hasDecl... strictly speaking
hasDecl is a function of TypedefType, while the others are more complex,
but I agree that it's just confusing.
Cheers,
/Manuel
>
> Thanks,
> Gábor
>
>
> On 22 October 2012 15:36, Gábor Horváth <xazax.hun at gmail.com> wrote:
>
>> Thanks!
>>
>> I'm now able to catch codes like this one: find(s.begin(),s.end(),i);
>> via a matcher like this:
>> callExpr(allOf(callee(functionDecl(hasName("std::find"))),
>> hasArgument(0,
>> hasDescendant(expr(hasType(typedefType(hasDecl(matchesName("std::(multiset|set).*::iterator"))))))))).bind("id")
>>
>>
>> On 22 October 2012 14:45, Manuel Klimek <klimek at google.com> wrote:
>>
>>> On Wed, Oct 17, 2012 at 7:11 PM, Gábor Horváth <xazax.hun at gmail.com>wrote:
>>>
>>>> To be correct, the code that I'm using for test, looks like this one:
>>>>
>>>> std::set<int>::iterator it2 = s.begin();
>>>> find(it2,s.end(),i);
>>>
>>>
>>> Looking at the AST:
>>> (CXXConstructExpr 0x489b058 <col:13> 'struct
>>> std::_Rb_tree_const_iterator<int>':'struct
>>> std::_Rb_tree_const_iterator<int>''void (const struct
>>> std::_Rb_tree_const_iterator<int> &) throw()'
>>> (ImplicitCastExpr 0x489b040 <col:13> 'const struct
>>> std::_Rb_tree_const_iterator<int>' lvalue <NoOp>
>>> (DeclRefExpr 0x489aa10 <col:13>
>>> 'std::set<int>::iterator':'struct std::_Rb_tree_const_iterator<int>' lvalue
>>> Var 0x48974d0 'it' 'std::set<int>::iterator':'struct
>>> std::_Rb_tree_const_iterator<int>')))
>>>
>>> I'd guess that after the ImplicitCastExpr the type is not the typedef'ed
>>> type any more...
>>>
>>> Cheers,
>>> /Manuel
>>>
>>>
>>>>
>>>> On 17 October 2012 19:00, Gábor Horváth <xazax.hun at gmail.com> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> I just tried out the new typedefType matcher. However there is one
>>>>> issue I encountered, maybe it is not intended to be used this way?
>>>>>
>>>>> This matcher matches:
>>>>> callExpr(allOf(callee(functionDecl(hasName("std::find"))),
>>>>> hasArgument(0,
>>>>> hasType(type()))))
>>>>>
>>>>> However this matcher do not match:
>>>>> callExpr(allOf(callee(functionDecl(hasName("std::find"))),
>>>>>
>>>>> hasArgument(0, hasType(typedefType()))))
>>>>>
>>>>> Do you have any idea what might be the problem? It compiles both ways.
>>>>>
>>>>> Thanks,
>>>>> Gábor
>>>>>
>>>>>
>>>>>
>>>>> On 12 October 2012 11:59, Manuel Klimek <klimek at google.com> wrote:
>>>>>
>>>>>>
>>>>>> On Fri, Oct 12, 2012 at 10:48 AM, Gábor Horváth <xazax.hun at gmail.com>wrote:
>>>>>>
>>>>>>> @Hal
>>>>>>>
>>>>>>> I'm using the tooling library, which is primarily for stand-alone
>>>>>>> tools, however I think it is also possible to use the matchers in the
>>>>>>> frontend, however I don't know, if it is advised (maybe Daniel or Manuel
>>>>>>> can tell this). If it isn't advised, it will be better to use a recursive
>>>>>>> AST visitor for this reason.
>>>>>>>
>>>>>>
>>>>>> It's not yet adviced - we're working on that, but we want to have
>>>>>> Doug & co. fully on board. One feature that's missing for that is being
>>>>>> able to run matchers on arbitrary parts of the AST (not only the full AST).
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 11 October 2012 16:06, Hal Finkel <hfinkel at anl.gov> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>> > From: "Gábor Horváth" <xazax.hun at gmail.com>
>>>>>>>> > To: "Manuel Klimek" <klimek at google.com>
>>>>>>>> > Cc: "Clang Developers" <cfe-dev at cs.uiuc.edu>
>>>>>>>> > Sent: Thursday, October 11, 2012 7:39:50 AM
>>>>>>>> > Subject: Re: [cfe-dev] Matching std::set::iterator
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Yeah, I need this for a tool for my thesis (finding common stl
>>>>>>>> > mistakes in code), but I can just use for example
>>>>>>>> > "std::_Rb_tree_const_iterator", and mention in my thesis, the
>>>>>>>> > current implementation only supports one certain STL
>>>>>>>> implementation,
>>>>>>>> > and will be improved in the future.
>>>>>>>> >
>>>>>>>> > But when some experimental patches are available, I will be happy
>>>>>>>> to
>>>>>>>> > test them out.
>>>>>>>> >
>>>>>>>>
>>>>>>>> [quasi-off-topic] I'm interested in how this turns out, not only
>>>>>>>> because I think that STL warnings will be a great thing to have, but also
>>>>>>>> because I'm interested in this optimization: I'd like to output TBAA
>>>>>>>> metadata so that the backend understands that pointers into distinct
>>>>>>>> std::vector objects (and maybe other containers?) don't alias. It seems
>>>>>>>> that implementing this will require the same kind of technology as what
>>>>>>>> you're doing.
>>>>>>>>
>>>>>>>> -Hal
>>>>>>>>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On 11 October 2012 14:32, Manuel Klimek < klimek at google.com >
>>>>>>>> wrote:
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Thu, Oct 11, 2012 at 1:28 PM, Gábor Horváth <
>>>>>>>> xazax.hun at gmail.com
>>>>>>>> > > wrote:
>>>>>>>> > > From my point of view, maybe something like matchesNameOrTypedef
>>>>>>>> > > would be
>>>>>>>> > > clean/easy. However I will be happy with any approach that
>>>>>>>> provides
>>>>>>>> > > an
>>>>>>>> > > obvious interface. I think not being able to match typedefs is
>>>>>>>> one
>>>>>>>> > > of the
>>>>>>>> > > biggest shortcomings of the matchers right now.
>>>>>>>> >
>>>>>>>> > Can you work around that by specifying the names it has been
>>>>>>>> > typedef'ed to for now?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > > On 11 October 2012 14:14, Manuel Klimek < klimek at google.com >
>>>>>>>> > > wrote:
>>>>>>>> > >>
>>>>>>>> > >> On Thu, Oct 11, 2012 at 12:03 PM, Daniel Jasper <
>>>>>>>> > >> djasper at google.com >
>>>>>>>> > >> wrote:
>>>>>>>> > >>>
>>>>>>>> > >>> We should make that decisions together with the Type/TypeLoc
>>>>>>>> > >>> matching.
>>>>>>>> > >>> I think looking through typedefs needs to be done with
>>>>>>>> matchers
>>>>>>>> > >>> for
>>>>>>>> > >>> types. matchesName()/hasName() on declarations should always
>>>>>>>> look
>>>>>>>> > >>> at
>>>>>>>> > >>> the name of the type used for the declaration and not at an
>>>>>>>> alias
>>>>>>>> > >>> defined in a typedef.
>>>>>>>> > >>
>>>>>>>> > >>
>>>>>>>> > >>
>>>>>>>> > >> I'm not sure I agree. It seems like the name property is really
>>>>>>>> > >> one of the
>>>>>>>> > >> decl or typedef, not one of the type.
>>>>>>>> > >>
>>>>>>>> > >> I'm curious about other opinions, though...
>>>>>>>> > >>
>>>>>>>> > >> Cheers,
>>>>>>>> > >> /Manuel
>>>>>>>> > >>
>>>>>>>> > >>>
>>>>>>>> > >>>
>>>>>>>> > >>> Cheers,
>>>>>>>> > >>> Daniel
>>>>>>>> > >>>
>>>>>>>> > >>> On Thu, Oct 11, 2012 at 11:47 AM, Manuel Klimek <
>>>>>>>> > >>> klimek at google.com >
>>>>>>>> > >>> wrote:
>>>>>>>> > >>> > On Thu, Oct 11, 2012 at 11:05 AM, Gábor Horváth <
>>>>>>>> > >>> > xazax.hun at gmail.com >
>>>>>>>> > >>> > wrote:
>>>>>>>> > >>> >> Hi!
>>>>>>>> > >>> >>
>>>>>>>> > >>> >> It looks like
>>>>>>>> > >>> >> ...hasType(namedDecl(matchesName("std::set.*iterator")))
>>>>>>>> > >>> >> ...
>>>>>>>> > >>> >> only tries to match ::std::_Rb_tree_const_iterator, but not
>>>>>>>> > >>> >> std::set<foobar>::iterator, so I basicaly can't match
>>>>>>>> > >>> >> typedefs. I
>>>>>>>> > >>> >> think it
>>>>>>>> > >>> >> is not possible to match on typedef-ed types right now.
>>>>>>>> > >>> >>
>>>>>>>> > >>> >> There is one test case:
>>>>>>>> > >>> >> EXPECT_TRUE(matches("typedef int X;", NamedX));
>>>>>>>> > >>> >>
>>>>>>>> > >>> >> However it matches a typedef declaration. However if we
>>>>>>>> wan't
>>>>>>>> > >>> >> to match
>>>>>>>> > >>> >> something like "X i;" later on, we can not do that,
>>>>>>>> however it
>>>>>>>> > >>> >> would
>>>>>>>> > >>> >> be
>>>>>>>> > >>> >> extremely useful.
>>>>>>>> > >>> >>
>>>>>>>> > >>> >> Any comments on this?
>>>>>>>> > >>> >
>>>>>>>> > >>> > We need to write a matcher that supports this. We already
>>>>>>>> have
>>>>>>>> > >>> > some of
>>>>>>>> > >>> > the supporting code for isDerivedFrom which looks through
>>>>>>>> > >>> > typedefs.
>>>>>>>> > >>> > We'll basically want to have a matcher matchesNameOrTypedef
>>>>>>>> > >>> > (minus
>>>>>>>> > >>> > finding a better name for the matcher ;) that does what you
>>>>>>>> > >>> > want.
>>>>>>>> > >>> >
>>>>>>>> > >>> > Cheers,
>>>>>>>> > >>> > /Manuel
>>>>>>>> > >>> >
>>>>>>>> > >>> >>
>>>>>>>> > >>> >> Thanks,
>>>>>>>> > >>> >> Gábor
>>>>>>>> > >>> >>
>>>>>>>> > >>> >>
>>>>>>>> > >>> >>
>>>>>>>> > >>> >> On 11 October 2012 09:39, Gábor Horváth <
>>>>>>>> xazax.hun at gmail.com
>>>>>>>> > >>> >> > wrote:
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> Hi!
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> More details on matching template specializations. After
>>>>>>>> > >>> >>> further
>>>>>>>> > >>> >>> trials I
>>>>>>>> > >>> >>> even tried this piece of code:
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> MatcherProxy StlCOAPPred::getMatcher()
>>>>>>>> > >>> >>> {
>>>>>>>> > >>> >>> TypeMatcher type = unless(anything());
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> for(const auto& e : gContainers)
>>>>>>>> > >>> >>> type = anyOf(hasDeclaration(recordDecl(hasName(e))),
>>>>>>>> type);
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> return id("id",
>>>>>>>> > >>> >>> varDecl(allOf(hasType(
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> classTemplateSpecializationDecl(hasAnyTemplateArgument(
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>>
>>>>>>>> refersToType(hasDeclaration(hasDescendant(recordDecl(hasName("std::auto_ptr")))))))),
>>>>>>>> > >>> >>> hasType(type))));
>>>>>>>> > >>> >>> }
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> If I remove the hasDescendant, it works flawlessly for
>>>>>>>> > >>> >>> example for
>>>>>>>> > >>> >>> vector<auto_ptr<int>>, however it will not fork for
>>>>>>>> > >>> >>> vector<vector<auto_ptr<int>>>. If I add that
>>>>>>>> hasDescendant it
>>>>>>>> > >>> >>> will
>>>>>>>> > >>> >>> not match
>>>>>>>> > >>> >>> anything. The same applies to the code I pasted in my mail
>>>>>>>> > >>> >>> earlier.
>>>>>>>> > >>> >>> If you
>>>>>>>> > >>> >>> have any idea what could cause this issue, please tell me.
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> Thanks,
>>>>>>>> > >>> >>> Gábor
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>> On 10 October 2012 15:37, Gábor Horváth <
>>>>>>>> xazax.hun at gmail.com
>>>>>>>> > >>> >>> > wrote:
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> For the second one, I altered my snippet:
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> MatcherProxy StlCOAPPred::getMatcher()
>>>>>>>> > >>> >>>> {
>>>>>>>> > >>> >>>> TypeMatcher type = unless(anything());
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> for(const auto& e : gContainers)
>>>>>>>> > >>> >>>> type = anyOf(hasDeclaration(recordDecl(hasName(e))),
>>>>>>>> type);
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> return id("id",
>>>>>>>> > >>> >>>> varDecl(allOf(hasType(recordDecl(hasDescendant(
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> classTemplateSpecializationDecl(hasAnyTemplateArgument(
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>>
>>>>>>>> refersToType(hasDeclaration(recordDecl(hasName("std::auto_ptr"))))))))),
>>>>>>>> > >>> >>>> hasType(type))));
>>>>>>>> > >>> >>>> }
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> But it does not seems to work. It do not give me any
>>>>>>>> > >>> >>>> matches.
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> For the first one, I futher will investigate it later
>>>>>>>> today,
>>>>>>>> > >>> >>>> however
>>>>>>>> > >>> >>>> my
>>>>>>>> > >>> >>>> bet would be that, it tries to match
>>>>>>>> > >>> >>>> "std::_Rb_tree_const_iterator".
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> Thanks,
>>>>>>>> > >>> >>>> Gábor
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>> On 10 October 2012 13:55, Daniel Jasper <
>>>>>>>> djasper at google.com
>>>>>>>> > >>> >>>> > wrote:
>>>>>>>> > >>> >>>>>
>>>>>>>> > >>> >>>>> +cfe-dev, please remember to include
>>>>>>>> > >>> >>>>>
>>>>>>>> > >>> >>>>> I don't see anything generally wrong with your approach
>>>>>>>> to
>>>>>>>> > >>> >>>>> match
>>>>>>>> > >>> >>>>> iterators. What I would do to debug this is locally
>>>>>>>> editing
>>>>>>>> > >>> >>>>> ASTMatchers.h to add a "llvm::outs() << FullName;" debug
>>>>>>>> > >>> >>>>> output
>>>>>>>> > >>> >>>>> into
>>>>>>>> > >>> >>>>> the matchesName matcher. That way, you can see what it
>>>>>>>> is
>>>>>>>> > >>> >>>>> actually
>>>>>>>> > >>> >>>>> trying to match.
>>>>>>>> > >>> >>>>>
>>>>>>>> > >>> >>>>> The second question should work like:
>>>>>>>> > >>> >>>>>
>>>>>>>> > >>> >>>>> varDecl(hasType(recordDecl(
>>>>>>>> > >>> >>>>>
>>>>>>>> > >>> >>>>>
>>>>>>>> hasDescendent(classTemplateSpecialization(hasAnyTemplateArgument(
>>>>>>>> > >>> >>>>> refersToType(hasName("std::auto_ptr")))))))).bind("id")
>>>>>>>> > >>> >>>>>
>>>>>>>> > >>> >>>>> This is just as a general idea, it might not yet be
>>>>>>>> > >>> >>>>> correct.
>>>>>>>> > >>> >>>>>
>>>>>>>> > >>> >>>>> Cheers,
>>>>>>>> > >>> >>>>> Daniel
>>>>>>>> > >>> >>>>>
>>>>>>>> > >>> >>>>> On Wed, Oct 10, 2012 at 1:23 PM, Gábor Horváth
>>>>>>>> > >>> >>>>> < xazax.hun at gmail.com >
>>>>>>>> > >>> >>>>> wrote:
>>>>>>>> > >>> >>>>> > Hi!
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > I want to create a matcher to match things like
>>>>>>>> > >>> >>>>> > std::set<int>::iterator.
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > I come up with this one: ...
>>>>>>>> > >>> >>>>> > hasType(namedDecl(matchesName("std::set.*iterator")))
>>>>>>>> ...
>>>>>>>> > >>> >>>>> > however it did not give me any match.
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > Using the internal name of the iterator class like
>>>>>>>> > >>> >>>>> > std::_Rb_tree_const_iterator would work, however that
>>>>>>>> is
>>>>>>>> > >>> >>>>> > implementation
>>>>>>>> > >>> >>>>> > defined, so I do not want to rely on that one.
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > Do you have any idea what am I doing wrong?
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > My another question is, for example if I want to
>>>>>>>> search
>>>>>>>> > >>> >>>>> > for
>>>>>>>> > >>> >>>>> > auto_ptr
>>>>>>>> > >>> >>>>> > as
>>>>>>>> > >>> >>>>> > template arguments in containers, I want to match
>>>>>>>> > >>> >>>>> > vector<auto_ptr<int>> and
>>>>>>>> > >>> >>>>> > also vector<vector<auto_ptr<int>>> ... etc.
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > Is there any proper way to do it? My current solution:
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > MatcherProxy StlCOAPPred::getMatcher()
>>>>>>>> > >>> >>>>> > {
>>>>>>>> > >>> >>>>> > TypeMatcher type = unless(anything());
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > for(const auto& e : gContainers)
>>>>>>>> > >>> >>>>> > type = anyOf(hasDeclaration(recordDecl(hasName(e))),
>>>>>>>> > >>> >>>>> > type);
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > auto templateSpecWithArgument = [](DeclarationMatcher
>>>>>>>> > >>> >>>>> > decl) ->
>>>>>>>> > >>> >>>>> > DeclarationMatcher {
>>>>>>>> > >>> >>>>> > return
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> classTemplateSpecializationDecl(hasAnyTemplateArgument(refersToType(hasDeclaration(decl))));
>>>>>>>> > >>> >>>>> > };
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > // 1, 2, 3 times embedded
>>>>>>>> > >>> >>>>> > DeclarationMatcher decl =
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> anyOf(templateSpecWithArgument(recordDecl(hasName("std::auto_ptr"))),
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> templateSpecWithArgument(templateSpecWithArgument(recordDecl(hasName("std::auto_ptr")))),
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> templateSpecWithArgument(templateSpecWithArgument(templateSpecWithArgument(recordDecl(hasName("std::auto_ptr"))))));
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > return
>>>>>>>> > >>> >>>>> > id("id",varDecl(allOf(hasType(decl),hasType(type))));
>>>>>>>> > >>> >>>>> > }
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > I use templateSpecWithArgument, and nesting it. I
>>>>>>>> could
>>>>>>>> > >>> >>>>> > write a
>>>>>>>> > >>> >>>>> > loop
>>>>>>>> > >>> >>>>> > to do
>>>>>>>> > >>> >>>>> > this nesting several times, however I think that could
>>>>>>>> > >>> >>>>> > degrade
>>>>>>>> > >>> >>>>> > the
>>>>>>>> > >>> >>>>> > performance significantly (I did not measure yet).
>>>>>>>> > >>> >>>>> >
>>>>>>>> > >>> >>>>> > Thanks
>>>>>>>> > >>> >>>>> > Gábor
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>>
>>>>>>>> > >>> >>>
>>>>>>>> > >>> >>
>>>>>>>> > >>> >>
>>>>>>>> > >>> >> _______________________________________________
>>>>>>>> > >>> >> 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
>>>>>>>> >
>>>>>>>>
>>>>>>>> --
>>>>>>>> Hal Finkel
>>>>>>>> Postdoctoral Appointee
>>>>>>>> Leadership Computing Facility
>>>>>>>> Argonne National Laboratory
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121023/488efff3/attachment.html>
More information about the cfe-dev
mailing list