[cfe-dev] cfe-dev Digest, Vol 80, Issue 85
Alangi Derick
alangiderick at gmail.com
Fri Feb 21 06:41:12 PST 2014
Hello
I am currently working on a task that i named Reversing the
Stages of Compilation. I saw a task on the GSOC GNU Compiler Collection on
http://gcc.gnu.org/wiki/SummerOfCode under the topic other projects and i
decided to work on that because i have an algorithm for that. But my main
problem now is having the working copy of GCC, i don't know where the
implementation of the cpp ( for preprocessing), -S option in GCC
(converting preprocessed file to assembly), As (gcc's portable tool for
creating machine language from assembly program) and ld (linking). At each
of these level, they have their code representation and i intern to reverse
this levels back to their original source code representation.
On Thu, Feb 20, 2014 at 8:08 PM, <cfe-dev-request at cs.uiuc.edu> wrote:
> Send cfe-dev mailing list submissions to
> cfe-dev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> or, via email, send a message with subject or body 'help' to
> cfe-dev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> cfe-dev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-dev digest..."
>
>
> Today's Topics:
>
> 1. Template matching question (Michael Steinberg)
> 2. Re: Template matching question (David Blaikie)
> 3. Re: Question about ASTMatchers (Richard)
> 4. Re: Question about ASTMatchers (Christian Schafmeister)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 20 Feb 2014 17:19:16 +0100
> From: Michael Steinberg <michael.steinberg at tu-clausthal.de>
> To: cfe-dev at cs.uiuc.edu
> Subject: [cfe-dev] Template matching question
> Message-ID: <53062B04.9090306 at tu-clausthal.de>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Hello,
> there is an interesting (for me) problem with luabind that you might be
> able to answer.
>
> Considering the template:
>
> template< typename T >
> void deduce( T (*)(), ... ) {}
>
> template< typename T >
> void deduce( T f, SomeType g ) {}
>
> ...more overloads...
>
> and the function:
>
> void foo() {
> throw some();
> }
>
> deduce( foo );
>
> clang 3.2 seems to add an implicit attribute "noreturn" (I assume that
> is because clang detected the function will never return). This
> attribute seems to rule out the given first overload of function
> template "deduce", which would otherwise be responsible to match the
> given function's signature and consequently fails on the second
> overload. Is that legal? Or maybe the mismatch is caused by another reason?
>
> Kind regards,
> Michael
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 20 Feb 2014 10:18:13 -0800
> From: David Blaikie <dblaikie at gmail.com>
> To: Michael Steinberg <michael.steinberg at tu-clausthal.de>
> Cc: cfe-dev Developers <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] Template matching question
> Message-ID:
> <
> CAENS6Ev02+2pKvcftX1T4R9+NpQbfddfPMHg0EOY91QzGbXoyQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Could you provide a standalone example of the problem? And include a log
> showing the file contents, the compiler version, the full command used to
> compile the source as well as all the output (error messages, etc)?
>
> My attempts to reproduce this with ToT Clang seem to have failed -
> something similar to what you described compiles without error.
>
>
> On Thu, Feb 20, 2014 at 8:19 AM, Michael Steinberg <
> michael.steinberg at tu-clausthal.de> wrote:
>
> > Hello,
> > there is an interesting (for me) problem with luabind that you might be
> > able to answer.
> >
> > Considering the template:
> >
> > template< typename T >
> > void deduce( T (*)(), ... ) {}
> >
> > template< typename T >
> > void deduce( T f, SomeType g ) {}
> >
> > ...more overloads...
> >
> > and the function:
> >
> > void foo() {
> > throw some();
> > }
> >
> > deduce( foo );
> >
> > clang 3.2 seems to add an implicit attribute "noreturn" (I assume that
> > is because clang detected the function will never return). This
> > attribute seems to rule out the given first overload of function
> > template "deduce", which would otherwise be responsible to match the
> > given function's signature and consequently fails on the second
> > overload. Is that legal? Or maybe the mismatch is caused by another
> reason?
> >
> > Kind regards,
> > Michael
> > _______________________________________________
> > 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/20140220/86b923b5/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 20 Feb 2014 12:08:24 -0700
> From: Richard <legalize at xmission.com>
> To: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] Question about ASTMatchers
> Message-ID: <E1WGYyu-0003pv-VQ at shell.xmission.com>
>
>
> In article <CAOsfVvmovo0mC4dX=
> 7Q9dWEno2BK6V6NiMxbkg0Nz9t+RUSjCg at mail.gmail.com>,
> Manuel Klimek <klimek at google.com> writes:
>
> > You might want to take a look at clang-query, which helps with
> > experimenting with matchers quickly (no compile needed, it uses the
> dynamic
> > matchers).
>
> Is there documentation on this? I couldn't find anything except some
> comments on the commit message.
> --
> "The Direct3D Graphics Pipeline" free book <
> http://tinyurl.com/d3d-pipeline>
> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
> The Terminals Wiki <http://terminals.classiccmp.org>
> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 20 Feb 2014 11:08:47 -0800
> From: Christian Schafmeister <chris.schaf at verizon.net>
> To: Manuel Klimek <klimek at google.com>
> Cc: clang-dev Developers <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] Question about ASTMatchers
> Message-ID: <4194C2BC-5625-4216-A8CD-96BC3EE04AA7 at verizon.net>
> Content-Type: text/plain; charset="windows-1252"
>
> I?m creating AST Matchers to match recordDecls and varDecls and match the
> types for the varDecls to recordDecls.
> In many cases the varDecls are instantiating template classes and some of
> the template classes are specialized.
>
> If I use this matcher:
> recordDecl(isTemplateInstantiation(),
> isSameOrDerivedFrom(recordDecl(hasName("BAR")))).bind(?WHOLE?) ?> FOO<A>
> node
> or
> recordDecl(isExplicitTemplateSpecialization(),
> isSameOrDerivedFrom(recordDecl(hasName("BAR")))).bind(?WHOLE?) ?>
> FOO<int> node
>
> How do I get the full name of the nodes that match and are bound to
> ?WHOLE??
>
> node.getName() ?> ?FOO? not ?FOO<A>? or ?FOO<int>"
>
>
>
> Here is the sample code:
>
> #include <stdio.h>
> #include <core/foundation.h>
> #include <core/object.h>
> #include <core/holder.h>
>
> namespace asttooling {
>
> class BAR {};
>
> template<typename T> class FOO : public BAR {};
> class A {};
>
> template<> class FOO<int> : public BAR {};
>
> void tinyFunc()
> {
> FOO<A> xa;
> FOO<int> xi;
> printf("Hi there, this is tinyFunc @%p %p\n", &xa, &xi);
> }
>
> };
>
>
> Christian Schafmeister
> chris.schaf at verizon.net
>
>
> On Feb 20, 2014, at 6:56 AM, Manuel Klimek <klimek at google.com> wrote:
>
> >
> > On Thu, Feb 20, 2014 at 3:49 PM, Christian Schafmeister <
> chris.schaf at verizon.net> wrote:
> > Manuel,
> >
> > I completely missed those predicates - thank you!
> >
> > How do I get the full name of an instantiated template recordDecl?
> >
> > As in:
> > template <class T> class X;
> > class A;
> >
> > X<A> xa;
> >
> > If a varDecl(?) matches on xa - how do I get the "X<A>? name?
> >
> > Do you want to "get" it or "match" it. Assuming you want to "get" it,
> you'd say something like varDecl(hasType(qualType().bind("t"))) (untested
> ;), and then in the callback extract the QualType and call getAsString() on
> it.
> >
> >
> > Best,
> >
> > .Chris.
> > Christian Schafmeister
> > chris.schaf at verizon.net
> >
> >
> > On Feb 20, 2014, at 12:53 AM, Manuel Klimek <klimek at google.com> wrote:
> >
> >> hasAncestor(decl(anyOf(recordDecl(
> >> isTemplateInstantiation()),
> >> functionDecl(isTemplateInstantiation()))
> >>
> >> should do what you want.
> >>
> >>
> >> On Wed, Feb 19, 2014 at 11:01 PM, Christian Schafmeister <
> chris.schaf at verizon.net> wrote:
> >>
> >> If I match a varDecl() that is in a method of a template class I get a
> match for the template and instantiated templates
> >> - is there a way to tell the difference by matching some difference in
> the ancestors of the varDecl node?
> >>
> >> I get a match for the translate::from_object<T> a0(*args); varDecl in
> the method activate (see below) that has this type:
> >> from_object<type-parameter-0-0, struct
> std::__1::integral_constant<_Bool, true> >
> >>
> >> I also get a match that I think is from the instantiation
> TestFunctoid<int> j(?test?) in tinyFunc - it has this type: "struct
> translate::from_object<int, std::true_type>"
> >>
> >> There is a clear difference in the name - but I was looking for
> something that didn?t feel like a hack.
> >>
> >> Are there differences in the AST class node for TestFunctoid when it is
> a template class vs when it is an instantiated template class?
> >>
> >>
> >>
> >> #include <stdio.h>
> >> #include <core/foundation.h>
> >> #include <core/object.h>
> >> #include <core/holder.h>
> >>
> >> namespace asttooling {
> >>
> >>
> >> template<typename T>
> >> class TestFunctoid : public core::Functoid {
> >> public:
> >>
> >> TestFunctoid(const string& name) : core::Functoid(name) {};
> >> core::T_mv activate( core::const_ActivationFrame_spREF
> closedOverFrame, int numArgs, ArgArray args )
> >> {
> >> translate::from_object<T> a0(*args);
> >> printf( "Address of a0= %p\n", &a0);
> >> return Values0<core::T_O>();
> >> }
> >> };
> >>
> >>
> >>
> >> void tinyFunc()
> >> {
> >> TestFunctoid<int> j("test");
> >> TinyStruct x(10);
> >> tinyFunc(x);
> >> printf("Hi there, this is tinyFunc\n");
> >> }
> >>
> >> };
> >>
> >> Christian Schafmeister
> >> Associate Professor
> >> Chemistry Department
> >> Temple University
> >>
> >>
> >
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140220/f74fb801/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> End of cfe-dev Digest, Vol 80, Issue 85
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140221/6cbc12e3/attachment.html>
More information about the cfe-dev
mailing list