Re: gcc extensibility

[Ludovic Courtès]

Hi,

Gabriel Dos Reis  skribis:

> I do not think people working on plugins have come up with a
> specification and an API they agree on.

I think it’s wrong to consider plug-ins as second-class citizens.

The plug-in mechanism is just a technical means to allow people to
extend the compiler without having to have their code checked in the
main tree.

Thanks,
Ludo’.

Re: Missed optimization in PRE?

[Richard Guenther]

On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng  wrote:
> On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther
>  wrote:
>> On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng  wrote:
>>> On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther
>>>  wrote:
 On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng  wrote:
> Hi,
> Following is the tree dump of 094t.pre for a test program.
> Question is loads of D.5375_12/D.5375_14 are redundant on path  bb7, bb5, bb6>,
> but why not lowered into basic block 3, where it is used.
>
> BTW, seems no tree pass handles this case currently.

 tree-ssa-sink.c should do this.

>>> It does not work for me, I will double check and update soon.
>>
>> Well, "should" as in, it's the place to do it.  And certainly the pass can 
>> sink
>> loads, so this must be a missed optimization.
>>
> Curiously, it is said explicitly that "We don't want to sink loads from 
> memory."
> in tree-ssa-sink.c function statement_sink_location, and the condition is
>
>  if (stmt_ends_bb_p (stmt)
>      || gimple_has_side_effects (stmt)
>      || gimple_has_volatile_ops (stmt)
>      || (gimple_vuse (stmt) && !gimple_vdef (stmt))
> <-check load
>      || (cfun->has_local_explicit_reg_vars
>          && TYPE_MODE (TREE_TYPE (gimple_assign_lhs (stmt))) == BLKmode))
>    return false;
>
> I haven't found any clue about this decision in ChangeLogs.

Ah, that's probably because usually you want to hoist loads and sink stores,
separating them (like a scheduler would do).  We'd want to restrict sinking
of loads to sink into not post-dominated regions (thus where they end up
being executed less times).

Richard.

>
> --
> Best Regards.

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Guenther]

On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson  wrote:
> On 03/29/2012 01:16 PM, Jan Hubicka wrote:
>>> Of course, there's still the problem of getting the unwind data correct at
>>> the point of the asm.  I commented about that in the PR you filed.
>>
>> I think i386 still has the problem that it is small register class target 
>> and if you
>> set rdi/rax and friends as hard registers, you risk reload failures.
>
> True, and if this were i386 code I would certainly recommend using the [acd]
> constraints instead (for suitible regparm signature).  But this is explicitly
> x86_64 code and the compiler has 8 registers otherwise available.
>
>> Do we prevent code motion of hard registers sets i.e. at GIMPLE level?

Yes we do (modulo bugs).

> I don't know for positive, but I'd certainly consider it a bug if we don't.
> There are plenty of targets which have no alternative but to use this style
> of programming for inline syscalls.
>
>
> r~

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Guenther]

On Thu, Mar 29, 2012 at 3:59 PM, Michael Matz  wrote:
> Hi,
>
> On Thu, 29 Mar 2012, Stephan Bergmann wrote:
>
>> > > Anyway, would it be worthwhile filing an RFE for an asm annotation
>> > > telling the compiler that it contains code that can throw?
>> >
>> > I suppose yes.
>>
>>  "RFE: Letting
>> compiler know asm block can call function that can throw."
>
> Actually, with -fnon-call-exceptions volatile asms are already supposed to
> be throwing.  It's just that this got lost with tree-ssa.  With the patch
> and -fnon-call-exceptions a simple "__asm__ volatile (...)" is regarded as
> possibly throwing.
>
> Without -fnon-call-exceptions some parser changes would be required.  How
> about "asm throw (...)" ?
>
>
> Ciao,
> Michael.
> Index: tree-eh.c
> ===
> --- tree-eh.c   (revision 183716)
> +++ tree-eh.c   (working copy)
> @@ -1959,6 +1959,7 @@ lower_eh_constructs_2 (struct leh_state
>       }
>       /* FALLTHRU */
>
> +    case GIMPLE_ASM:
>     case GIMPLE_ASSIGN:
>       /* If the stmt can throw use a new temporary for the assignment
>          to a LHS.  This makes sure the old value of the LHS is

This does not handle using a temporary for all (register) outputs ...
I suppose the code should walk all SSA defs instead of looking at
the LHS only.

> Index: tree-cfg.c
> ===
> --- tree-cfg.c  (revision 183716)
> +++ tree-cfg.c  (working copy)
> @@ -580,6 +580,8 @@ make_edges (void)
>
>            case GIMPLE_ASM:
>              make_gimple_asm_edges (bb);
> +             if (is_ctrl_altering_stmt (last))
> +               make_eh_edges (last);
>              fallthru = true;
>              break;

Otherwise this looks reasonable.  With a testcase, I suppose ;)

Richard.

Re: Proposed plugin API for GCC

[Ludovic Courtès]

Hi,

David Malcolm  skribis:

> How do other plugin authors feel about the API?

I think this approach would lead to a duplication of each GCC API.

The needs of plug-ins cannot be anticipated; artificially restricting
what plug-ins can do is likely to hinder wider extension of GCC.

As an example, when Emacs was written, probably nobody expected that
email and IRC clients would be written in it; likewise, probably most of
the projects at  were not anticipated.


What about sticking to the current “API” instead, and explicitly marking
as internal those parts that core developers know are still in flux?

For instance, I would expect a large subset of  and 
to be stable (it’s been the case in my experience between 4.5 and 4.7.)
The rest can be tagged with a special convention (for instance, an ‘i_’
prefix), to make it clear that it’s only meant for internal consumption.

WDYT?

Thanks,
Ludo’.

Re: Proposed plugin API for GCC

[Richard Guenther]

On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès
 wrote:
> Hi,
>
> David Malcolm  skribis:
>
>> How do other plugin authors feel about the API?
>
> I think this approach would lead to a duplication of each GCC API.

I would call it an abstraction of GCC internals (disclaimer: I did not look
at the proposed API).  This abstraction should be easier to learn and
easier to use for 99% of the plugin users.  And it should offer a stable
abstraction ABI that makes plugins interoperate with different GCC versions
without recompiling.

> The needs of plug-ins cannot be anticipated; artificially restricting
> what plug-ins can do is likely to hinder wider extension of GCC.

Extension of GCC should happen within the GCC codebase.  Plugins
are not a replacement of improving GCC!

> As an example, when Emacs was written, probably nobody expected that
> email and IRC clients would be written in it; likewise, probably most of
> the projects at  were not anticipated.
>
>
> What about sticking to the current “API” instead, and explicitly marking
> as internal those parts that core developers know are still in flux?

That's not possible.  And it is not wanted.

> For instance, I would expect a large subset of  and 
> to be stable (it’s been the case in my experience between 4.5 and 4.7.)
> The rest can be tagged with a special convention (for instance, an ‘i_’
> prefix), to make it clear that it’s only meant for internal consumption.
>
> WDYT?

Sounds like a stupid idea that does not work (yes, plugins that want to
do everything an embedded part of GCC can do are stupid).

Richard.

> Thanks,
> Ludo’.
>

Re: gcc extensibility

[Richard Guenther]

On Fri, Mar 30, 2012 at 9:14 AM, Ludovic Courtès
 wrote:
> Hi,
>
> Gabriel Dos Reis  skribis:
>
>> I do not think people working on plugins have come up with a
>> specification and an API they agree on.
>
> I think it’s wrong to consider plug-ins as second-class citizens.
>
> The plug-in mechanism is just a technical means to allow people to
> extend the compiler without having to have their code checked in the
> main tree.

No, that means would be using the old tool named 'patch' before building
GCC.

Richard.

> Thanks,
> Ludo’.
>

Re: Proposed plugin API for GCC

[Romain Geissler]

Hi

Le 30 mars 2012 à 06:18, Ian Lance Taylor a écrit :

> I would recommend grouping functions by category, and making each
> category be a struct with a set of function pointers.  That will give
> you a namespace, and will greatly reduce the number of external names in
> the API.
> 
> Ian

Using structs with some sets of function pointers may break compatibility
between minor release.

Imagine i've got the following struct publicly exported in 4.7.1 :

struct GCC_plugin_tree_functions{
GCC_plugin_tree_code (*get_code)(GCC_plugin_tree tree);
bool (*is_used)(GCC_plugin_tree tree);
}

Now some plugin writer needs to know if a tree is a constant. We add it in 
4.7.2 :

struct GCC_plugin_tree_functions{
GCC_plugin_tree_code (*get_code)(GCC_plugin_tree tree);
bool (*is_constant)(GCC_plugin_tree tree);
bool (*is_used)(GCC_plugin_tree tree);
}

We insert is_constant between get_code and is_used to reflect the actual
flag order defined in tree_base. But if we proceed that way, a plugin will
have to be rebuild with every gcc release, even if the plugin API is fully
backward compatible (ie we only added new feature without changing the
old ones).

Anyway, you're suggestion to group functions in common names, that's just
C++ motto. May the eventual plugin API in C++ (independently from internals
being C++ or not) ?

Romain Geissler

Re: Proposed plugin API for GCC

[Basile Starynkevitch]

On Fri, Mar 30, 2012 at 10:23:16AM +0200, Ludovic Courtès wrote:
> Hi,
> 
> David Malcolm  skribis:
> 
> > How do other plugin authors feel about the API?
> 
> I think this approach would lead to a duplication of each GCC API.
> 
> The needs of plug-ins cannot be anticipated; artificially restricting
> what plug-ins can do is likely to hinder wider extension of GCC.
> 
> As an example, when Emacs was written, probably nobody expected that
> email and IRC clients would be written in it; likewise, probably most of
> the projects at  were not anticipated.


I entirely agree with the above statements. More generally, we cannot
predict what plugins will be written for GCC, and what part of the API they
will use, and for what purposes they will be written. I guess than most
plugins would provide something which would not have its place inside GCC.
(I also guess that some plugins might be written to experiment passes which
could go inside GCC, but which won't be proposed quickly into GCC, in
particular because having a patch being reviewed and accepted, when that
patch comes from a newbie, is very time consuming).


> 
> What about sticking to the current ???API??? instead, and explicitly marking
> as internal those parts that core developers know are still in flux?

I tend to like that, but my feeling is that there might not be a consensus
on what the current API is, and on what the API used by plugins should be.

(I have the impression that people discussing that on gcc@ list tend to
attach slightly different meanings to these terms)

 
> For instance, I would expect a large subset of  and 
> to be stable (it???s been the case in my experience between 4.5 and 4.7.)
> The rest can be tagged with a special convention (for instance, an ???i_???
> prefix), to make it clear that it???s only meant for internal consumption.

I like that approach. I also feel that the headers should contain structured
comments from which some (imperfect) documentation of (an imperfect API)
could be produced.

Regards.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

MELT 0.9.5rc1 etc...

[Basile Starynkevitch]

Hello

If you want to help me on the makefile issues for the next MELT plugin
release 0.9.5, please extract the MELT plugin from the svn repository, since
I am making small changes (which still don't work) since 0.9.5rc1

The procedure to extract the MELT plugin from the MELT brannch is:

Retrieve the MELT branch if you don't have it

   svn co svn://gcc.gnu.org/svn/gcc/branches/melt-branch gcc-melt

Go into it

   cd gcc-melt

Run the update to be sure to have the latest SVN & to gernerate the REVISION
etc files

   ./contrib/gcc_update

Run the following script to get the MELT plugin tarball

   ./contrib/make-melt-source-tar.sh $PWD /tmp/meltplugin

You now should have a /tmp/meltplugin.tar.gz which is the MELT plugin
tarball corresponding to your state of the MELT branch

Regards.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Missed optimization in PRE?

[Bin.Cheng]

On Fri, Mar 30, 2012 at 4:15 PM, Richard Guenther
 wrote:
> On Thu, Mar 29, 2012 at 5:25 PM, Bin.Cheng  wrote:
>> On Thu, Mar 29, 2012 at 6:14 PM, Richard Guenther
>>  wrote:
>>> On Thu, Mar 29, 2012 at 12:10 PM, Bin.Cheng  wrote:
 On Thu, Mar 29, 2012 at 6:07 PM, Richard Guenther
  wrote:
> On Thu, Mar 29, 2012 at 12:02 PM, Bin.Cheng  wrote:
>> Hi,
>> Following is the tree dump of 094t.pre for a test program.
>> Question is loads of D.5375_12/D.5375_14 are redundant on path > bb7, bb5, bb6>,
>> but why not lowered into basic block 3, where it is used.
>>
>> BTW, seems no tree pass handles this case currently.
>
> tree-ssa-sink.c should do this.
>
 It does not work for me, I will double check and update soon.
>>>
>>> Well, "should" as in, it's the place to do it.  And certainly the pass can 
>>> sink
>>> loads, so this must be a missed optimization.
>>>
>> Curiously, it is said explicitly that "We don't want to sink loads from 
>> memory."
>> in tree-ssa-sink.c function statement_sink_location, and the condition is
>>
>>  if (stmt_ends_bb_p (stmt)
>>      || gimple_has_side_effects (stmt)
>>      || gimple_has_volatile_ops (stmt)
>>      || (gimple_vuse (stmt) && !gimple_vdef (stmt))
>> <-check load
>>      || (cfun->has_local_explicit_reg_vars
>>          && TYPE_MODE (TREE_TYPE (gimple_assign_lhs (stmt))) == BLKmode))
>>    return false;
>>
>> I haven't found any clue about this decision in ChangeLogs.
>
> Ah, that's probably because usually you want to hoist loads and sink stores,
> separating them (like a scheduler would do).  We'd want to restrict sinking
> of loads to sink into not post-dominated regions (thus where they end up
> being executed less times).
>
Understood, I will work on this.
Thanks.

-- 
Best Regards.

Re: Proposed plugin API for GCC

[Ludovic Courtès]

Hi Richard,

Richard Guenther  skribis:

> On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès

[...]

>> The needs of plug-ins cannot be anticipated; artificially restricting
>> what plug-ins can do is likely to hinder wider extension of GCC.
>
> Extension of GCC should happen within the GCC codebase.  Plugins
> are not a replacement of improving GCC!

Yes, I agree.

However, I’m sure that GCC can be extended in ways that are very
valuable, yet that would not fit in GCC itself for various
administrative or technical reasons.

I find it important to help such unanticipated uses of GCC spread.

>> For instance, I would expect a large subset of  and 
>> to be stable (it’s been the case in my experience between 4.5 and 4.7.)
>> The rest can be tagged with a special convention (for instance, an ‘i_’
>> prefix), to make it clear that it’s only meant for internal consumption.
>>
>> WDYT?
>
> Sounds like a stupid idea that does not work

The current situation is that nothing, or everything, is considered
internal, depending on who you ask.  ;-)

The above suggestion would be a recognition that yes, plug-ins /do/ need
 & co. to do anything meaningful, but at the same time that
parts of it are internal and /will/ break eventually.

Thanks,
Ludo’.

Re: gcc extensibility

[Bernd Schmidt]

On 03/30/2012 10:37 AM, Richard Guenther wrote:
> On Fri, Mar 30, 2012 at 9:14 AM, Ludovic Courtès
>  wrote:
>> Hi,
>>
>> Gabriel Dos Reis  skribis:
>>
>>> I do not think people working on plugins have come up with a
>>> specification and an API they agree on.
>>
>> I think it’s wrong to consider plug-ins as second-class citizens.
>>
>> The plug-in mechanism is just a technical means to allow people to
>> extend the compiler without having to have their code checked in the
>> main tree.
> 
> No, that means would be using the old tool named 'patch' before building
> GCC.

Or even the new tool named 'git'.


Bernd

Re: Proposed plugin API for GCC

[Gabriel Dos Reis]

On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès
 wrote:

> What about sticking to the current “API” instead, and explicitly marking
> as internal those parts that core developers know are still in flux?

A guarantee of perpetual discussions of the same topic, over and over.
(meh, GCC-x.y.z just broke my plugins; this is unacceptable, blah blah bah.)

-- Gaby

Re: Proposed plugin API for GCC

[Gabriel Dos Reis]

On Fri, Mar 30, 2012 at 4:33 AM, Basile Starynkevitch
 wrote:

> I entirely agree with the above statements. More generally, we cannot
> predict what plugins will be written for GCC, and what part of the API they
> will use, and for what purposes they will be written.

I believe somethings is being lost here:

   plugins people: we don't want to define an API.
   GCC maintainers: you have to define an API or you're doomed to
be stuck forever.

Loop forever.

-- Gaby

Re: Proposed plugin API for GCC

[Richard Guenther]

On Fri, Mar 30, 2012 at 1:54 PM, Gabriel Dos Reis
 wrote:
> On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès
>  wrote:
>
>> What about sticking to the current “API” instead, and explicitly marking
>> as internal those parts that core developers know are still in flux?
>
> A guarantee of perpetual discussions of the same topic, over and over.
> (meh, GCC-x.y.z just broke my plugins; this is unacceptable, blah blah bah.)

Yeah.  Btw, the alternative to a stable plugin API is embedded support of
a scripting language (python, guile, etc.).  That's of course just another
supposed-to-be stable "plugin API".  Both are sufficient for introspection
and instrumentation tasks (a good test if the API is powerful enough is
to implement mudflap with it).

Richard.

Re: Proposed plugin API for GCC

[Gabriel Dos Reis]

On Fri, Mar 30, 2012 at 4:45 AM, Ludovic Courtès
 wrote:

> I find it important to help such unanticipated uses of GCC spread.

It is hard to design for things you do not know.  How about starting
with things you do know?  A possible path to progress on this issue, no?

-- Gaby

Re: Proposed plugin API for GCC

[Gabriel Dos Reis]

On Fri, Mar 30, 2012 at 6:59 AM, Richard Guenther
 wrote:
> On Fri, Mar 30, 2012 at 1:54 PM, Gabriel Dos Reis
>  wrote:
>> On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès
>>  wrote:
>>
>>> What about sticking to the current “API” instead, and explicitly marking
>>> as internal those parts that core developers know are still in flux?
>>
>> A guarantee of perpetual discussions of the same topic, over and over.
>> (meh, GCC-x.y.z just broke my plugins; this is unacceptable, blah blah bah.)
>
> Yeah.  Btw, the alternative to a stable plugin API is embedded support of
> a scripting language (python, guile, etc.).  That's of course just another
> supposed-to-be stable "plugin API".  Both are sufficient for introspection
> and instrumentation tasks (a good test if the API is powerful enough is
> to implement mudflap with it).

Exactly right.  I had some hope that the plugins people would coalesce behind
David M.'s proposal as a starting point, but now I don't know if the plugin
case has any merit anymore :-/

-- Gaby

Re: gcc extensibility

[Gabriel Dos Reis]

On Fri, Mar 30, 2012 at 2:14 AM, Ludovic Courtès
 wrote:
> Hi,
>
> Gabriel Dos Reis  skribis:
>
>> I do not think people working on plugins have come up with a
>> specification and an API they agree on.
>
> I think it’s wrong to consider plug-ins as second-class citizens.

Nobody has made that assertion that you are finding wrong so far.

> The plug-in mechanism is just a technical means to allow people to
> extend the compiler without having to have their code checked in the
> main tree.

That was understood.

-- Gaby

Re: Proposed plugin API for GCC

[Richard Guenther]

On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm  wrote:
> I had a go at writing a possible plugin API for GCC, and porting parts
> of my python plugin to it:
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e
>
> It's very much at the "crude early prototype" stage - all I've wrapped
> is part of CFG-handling - but the important thing is that python plugin
> *does* actually compile against this, and many of its selftests still
> pass (though I'm breaking the self-imposed encapsulation in quite a few
> places in order to get it to compile).
>
> The code is currently jointly owned by me and Red Hat; I'm sure we can
> do copyright assignment if/when it comes to that.
>
> You can see the work-in-progress in the "proposed-plugin-api" branch of
> gcc-python-plugin.
>
> For example, the proposed public header file looks like this:
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=proposed-plugin-api/gcc-cfg.h;h=8dbeed0a6c5eb14b0336e89493746887c3bec20a;hb=36a0d6a45473c39db550915f8419a794f2f5653e
>
> For example, some design notes can be seen at:
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=proposed-plugin-api/design.rst;h=31b960ccac2dcf4d007701b5e9c6556e68e0d107;hb=36a0d6a45473c39db550915f8419a794f2f5653e
>
> How do other plugin authors feel about the API?

Of course I don't like the CamelCasing ;)

The important part of the API is that it exposes no data structures and
all object references we expose are opaque.

You have mostly wrapped in an iterator-style way, I suppose that's fine.
That (and the CamelCasing) exposes that using a different language for
this API would be desired; use namespaces to avoid CamelCasing and
STL style iterators / functors for the rest.  If you stay with C rather
than using callbacks I would use an explicit iterator representation,
similar to how we have that now with gimple_stmt_iterator.  Of course
that's personal preference, subject to bikeshedding.

Would the python plugin have any issue with using C++?

> How do GCC subsystem maintainers feel?

Well, positive!  Thanks for starting.  CFG introspection is indeed one
of the most important parts, then callgraph and statement introspection.

> I initially attempted an underscore_based_naming_convention but quickly
> found it difficult to get concise function names, so I switched to a
> CamelCaseBased_NamingConvention with an underscore separating a notional
> namespace element from a secondary element, which saved plenty of space.
> The different naming convention also serves to highlight that this is
> *not* part of GCC's internals.
>
> Hope this is constructive

Indeed, and thank you for that.

Btw, how ugly is it to make this API grokable by swig?  Would that serve
the python plugin?

Thanks,
Richard.

Re: C++: Letting compiler know asm block can call function that can throw?

[Jan Hubicka]

> On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson  wrote:
> > On 03/29/2012 01:16 PM, Jan Hubicka wrote:
> >>> Of course, there's still the problem of getting the unwind data correct at
> >>> the point of the asm.  I commented about that in the PR you filed.
> >>
> >> I think i386 still has the problem that it is small register class target 
> >> and if you
> >> set rdi/rax and friends as hard registers, you risk reload failures.
> >
> > True, and if this were i386 code I would certainly recommend using the [acd]
> > constraints instead (for suitible regparm signature).  But this is 
> > explicitly
> > x86_64 code and the compiler has 8 registers otherwise available.

Sure, still rdi/rax is the only option for some of instructions, so x86-64
doesn't really solve all the problems.
> >
> >> Do we prevent code motion of hard registers sets i.e. at GIMPLE level?
> 
> Yes we do (modulo bugs).

Good. Note that this also include transformations like frward substitution into
area where hard register is live (i.e. it is not enough to just not touch hard
registers as volatile, but one needs to prevent moving other code in).

Honza
> 
> > I don't know for positive, but I'd certainly consider it a bug if we don't.
> > There are plenty of targets which have no alternative but to use this style
> > of programming for inline syscalls.
> >
> >
> > r~

Re: C++: Letting compiler know asm block can call function that can throw?

[Richard Guenther]

2012/3/30 Jan Hubicka :
>> On Thu, Mar 29, 2012 at 8:34 PM, Richard Henderson  wrote:
>> > On 03/29/2012 01:16 PM, Jan Hubicka wrote:
>> >>> Of course, there's still the problem of getting the unwind data correct 
>> >>> at
>> >>> the point of the asm.  I commented about that in the PR you filed.
>> >>
>> >> I think i386 still has the problem that it is small register class target 
>> >> and if you
>> >> set rdi/rax and friends as hard registers, you risk reload failures.
>> >
>> > True, and if this were i386 code I would certainly recommend using the 
>> > [acd]
>> > constraints instead (for suitible regparm signature).  But this is 
>> > explicitly
>> > x86_64 code and the compiler has 8 registers otherwise available.
>
> Sure, still rdi/rax is the only option for some of instructions, so x86-64
> doesn't really solve all the problems.
>> >
>> >> Do we prevent code motion of hard registers sets i.e. at GIMPLE level?
>>
>> Yes we do (modulo bugs).
>
> Good. Note that this also include transformations like frward substitution 
> into
> area where hard register is live (i.e. it is not enough to just not touch hard
> registers as volatile, but one needs to prevent moving other code in).

Motion across hardreg sets/uses are not restricted.  And I would not expect
an optimizing compiler to do that (it's your own fault to use hardregs in
complex C code).

Richard.

FSF Legal Documentation

[Subrata Biswas]

Dear All,
I want to contribute GCC during this summer as my GSoC project and even
after this summer as an active member of GCC community. I have heard about
the essential legal documentation process and I also send a request mail to
assignme...@gnu.org yesterday. But I did not get any response from them.

What should be my next step?
--
Thanking You,
Regards,
Subrata Biswas
MTech (pursuing)
Computer Science and Engineering
Indian Institute of Technology, Roorkee
Roorkee , India





--
Thanking You,
Regards,

Subrata Biswas
MTech (pursuing)
Computer Science and Engineering
Indian Institute of Technology, Roorkee
Roorkee , India

how to generate 64 bit relocations with gcc 3.3.3

[Zhang Chong]

Hi, gcc-help,

Can anyone tell me that how to generate only 64bit relocations binary
with gcc 3.3? Thanks for the help


Regards,
Zhang,Chong

Re: FSF Legal Documentation

[Diego Novillo]

On 3/30/12 8:52 AM, Subrata Biswas wrote:

Dear All,
I want to contribute GCC during this summer as my GSoC project and even
after this summer as an active member of GCC community. I have heard about
the essential legal documentation process and I also send a request mail to
assignme...@gnu.org yesterday. But I did not get any response from them.


I have sent you the assignment form in a separate message.


What should be my next step?


Once you fill-in the form, there is nothing for you to do until you hear 
back from the FSF.  You can continue developing, of course.  You only 
need the paperwork done prior to committing your work to the repository.



Diego.

Re: Proposed plugin API for GCC

[Basile Starynkevitch]

On Fri, Mar 30, 2012 at 02:14:31PM +0200, Richard Guenther wrote:
> 
> Btw, how ugly is it to make this API grokable by swig?  Would that serve
> the python plugin?


An alternative would be to have either some easily parsable API definition
(wwhich might be sort-of offered by Swig, but I'll bet that not in practice:
we'll need to use weird Swig tricks), or some way of querying at runtime that 
API.

The important part in my view is that such an API should not be targeted to
Python only. It should be usable by plugins coded in C++ (or in MELT), or in
other languages.

Again, the GTK guys did a good work with their Gobject introspection layer,
which is a meta-API providing that.

The point is that GCC will stay complex, and any API will by necessity be
huge. We have to know that and to ease it uses (e.g. to facilitate the
embedding of several scripting languages, not only Python).

So it really would help if the API is documented and mechanically queryable.

A traditional manual glue code is not enough.

(And there might be memory management issue; we have to specify very well
when a GCC data should be released, and by whom. I feel that Ggc is part of
the solution).

Cheers.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Proposed plugin API for GCC

[Ian Lance Taylor]

Romain Geissler  writes:

> Using structs with some sets of function pointers may break compatibility
> between minor release.

Yes, but fortunately we have a good understanding of how not to do that.

We could also go the even safer route used for linker plugins, in which
the plugin is invoked with a list of functions, where each function is
tagged with a code.  See include/plugin-api.h for the interface and
lto-plugin for an implementation.  The approach there is very clean and
permits forward and backward binary compatibility.  I don't know if we
want to go that far for compiler plugins.


> Anyway, you're suggestion to group functions in common names, that's just
> C++ motto. May the eventual plugin API in C++ (independently from internals
> being C++ or not) ?

I think we have a clear understanding of how to maintain compatibility
across releases in C.  I do not think we have that understanding in C++.

Ian

Re: Proposed plugin API for GCC

[Ludovic Courtès]

Gabriel Dos Reis  skribis:

> On Fri, Mar 30, 2012 at 4:45 AM, Ludovic Courtès
>  wrote:
>
>> I find it important to help such unanticipated uses of GCC spread.
>
> It is hard to design for things you do not know.

Indeed, that’s the whole point.  Offer a ten-function stable API and
watch “plug-in people”, as you put it, do compiler work on top of LLVM.
As simple as this.

Ludo’.

Re: Proposed plugin API for GCC

[Ian Lance Taylor]

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> What about sticking to the current “API” instead, and explicitly marking
> as internal those parts that core developers know are still in flux?
>
> For instance, I would expect a large subset of  and 
> to be stable (it’s been the case in my experience between 4.5 and 4.7.)
> The rest can be tagged with a special convention (for instance, an ‘i_’
> prefix), to make it clear that it’s only meant for internal consumption.

This is an interesting goal but it is essentially impossible to
implement.  In both theory and practice, it's all in flux.  GCC has been
around for 25 years.  Everything has changed in that time, and most
things have changed multiple times.

We do not want plugins to constrain internal development.  So if we
adopted your approach, the only honest option would be to mark
everything as internal.  And that would leave us where we are today.

Ian

Re: how to generate 64 bit relocations with gcc 3.3.3

[Ian Lance Taylor]

"张翀(Zhang Chong)"  writes:

> Hi, gcc-help,

Please never send e-mail to both gcc-h...@gcc.gnu.org and
gcc@gcc.gnu.org.  Please send any followups only to gcc-help.  Thanks.


> Can anyone tell me that how to generate only 64bit relocations binary
> with gcc 3.3? Thanks for the help

I don't understand your question.  Can you give an example of what you
mean.

Perhaps you mean: can anybody tell you how to generate 64-bit code for
the x86 using gcc 3.3.  In GCC this is called x86_64, so the answer is
to configure your compiler for the x86_64 target.  See the installation
documentation.

Note that gcc 3.3 is very very old.  The current version is 4.7.0.

Ian

Re: Proposed plugin API for GCC

[Ludovic Courtès]

Ian Lance Taylor  skribis:

> We do not want plugins to constrain internal development.  So if we
> adopted your approach, the only honest option would be to mark
> everything as internal.  And that would leave us where we are today.

My (limited) experience suggests that things aren’t that bad between 4.5
and 4.7, at least for the tree, cgraph, and gimple subsets that my
plug-in uses.

My feeling is that there aren’t so many ways to design the core of these
three APIs, anyway.  But surely your hindsight could help understand and
anticipate API changes.

Thanks,
Ludo’.

Re: Proposed plugin API for GCC

[Gabriel Dos Reis]

On Fri, Mar 30, 2012 at 9:48 AM, Ludovic Courtès
 wrote:
> Ian Lance Taylor  skribis:
>
>> We do not want plugins to constrain internal development.  So if we
>> adopted your approach, the only honest option would be to mark
>> everything as internal.  And that would leave us where we are today.
>
> My (limited) experience suggests that things aren’t that bad between 4.5
> and 4.7, at least for the tree, cgraph, and gimple subsets that my
> plug-in uses.

Yes, but the time span between 4.5 and 4.7 is relatively small compared
to, say the EGCS days, or even the 3.x.y days.  A lot has changed.  I do
actually expect a lot to change in the 4.8-4.10 time frame once we
agreed on rules governing C++ usage in GCC -- I can tell you that we
have several projects in the pipeline.

-- Gaby

Re: C++: Letting compiler know asm block can call function that can throw?

[Jan Hubicka]

> 
> Motion across hardreg sets/uses are not restricted.  And I would not expect
> an optimizing compiler to do that (it's your own fault to use hardregs in
> complex C code).

Well, the syscall sequence is an example of somehting that should be inlined
into arbitrary code w/o potential risk of ICEs.  But I guess if things works in
practice (as they seem), we don't need to worry much at the moment.  Most of
code movement we do is very simple. I don't see how to convince GCC to move
memcpy or division into the middle of a basic block containing the libcall
sequence Even when the basic block can be broken up with
-fno-call-exceptions at the asm statement by an EH edge...

Honza
> 
> Richard.

About ARM-cross-compile

[Mao Ito]

Hi everyone,

I am a grad student at UW-Madison who asked a question before about gcc-cross 
compiler.
I got stuck on a problem. 
Actually, I could install "arm-eabi" cross-compiler for c, c++.
The problem is about "arm-eabi-gcj" (i.e. for Java).
"arm-elf" version cross-compiler was successfully installed for c, c++, Java. 
But, after that, I realized that my simulator does not accept OABI binary code 
(i.e. binary code "arm-elf" compiler generates). So, I need to install 
"arm-eabi" version cross-compiler because the simulator can accept EABI binary 
code.

So, recently, I was struggling to install "arm-eabi-gcj" into my laptop. 
The problem is about "libgcj.jar" file. 
I could download "libgcj-4.1.2-51.el5.x86_64.rpm" from this web-site 
http://rpm.pbone.net/index.php3/stat/4/idpl/16997778/dir/scientific_linux_5/com/libgcj-4.1.2-51.el5.x86_64.rpm.html.
The problem is that this is RPM file so that I need to get "RPM-GPG-KEY" for 
this rpm file to unlock it. 
However, I cannot find this key. Does somebody have some idea about where I can 
get this key?
Actually, I could install "arm-eabi" for c, c++. So, we are thinking that we 
use c++. But, we would like to use Java. So, does someone know about how I can 
get GPG-KEY for libgcj.jar or other way.
Thank you for reading!

Sincerely,
Mao Ito

C++ va_list wromng code generation in class::method(...,va_list args) only

[Bernd Roesch]

hello

there is a C++ game called dunelegacy which work on other GCC architecture ok
On G++ 68k it compile ok, but produce wrong code, because there seem something 
diffrent in
va_list. The value of
SDL_RWops is transfer wrong.

I do not understand what backend problem is possible to cause this. Please 
help.va_list use the
builtin GCC functions

this happen on all 68k compilers i test. (3.x and some 4.x)

See also the source attached of this class

the program flow of the critical part begin here. 

Wsafile::Wsafile(SDL_RWops* RWop)
{
readdata(1,RWop);
}

..


now there are 2 Methods named readdata, and gcc call the 2. one. This work 
wrong. Only when called
the first is ok.

.

void Wsafile::readdata(int NumFiles, ...) {
va_list args;
va_start(args,NumFiles);
readdata(NumFiles,args);
va_end(args);
}

/// Helper method for reading and concatinating various WSA-Files.
/**
This methods reads from the RWops all data and concatinates all the frames 
to one animation. The
SDL_RWops
can be readonly but must support seeking.
\param  NumFilesNumber of SDL_RWops
\param  argsSDL_RWops for each wsa-File should be in this va_list. 
(can be readonly)
*/
void Wsafile::readdata(int NumFiles, va_list args) {
unsigned char** Filedata;
Uint32** Index;
Uint16* NumberOfFrames;
bool* extended;

if((Filedata = (unsigned char**) malloc(sizeof(unsigned char*) * NumFiles)) 
== NULL) {
fprintf(stderr, "Wsafile::readdata(): Unable to allocate memory!\n");
exit(EXIT_FAILURE);
}


.


when i change code to this and rename the first readdata method to 
readdata_first then it work

Wsafile::Wsafile(SDL_RWops* RWop)
{
readdata_first(1,RWop);   < I change that line
}

now there is called this method before and all work ok


void Wsafile::readdata_frist(int NumFiles, ...) {   < I rename readdata to 
readdata_first.
va_list args;
va_start(args,NumFiles);
readdata(NumFiles,args);
va_end(args);
}

/// Helper method for reading and concatinating various WSA-Files.
/**
This methods reads from the RWops all data and concatinates all the frames 
to one animation. The
SDL_RWops
can be readonly but must support seeking.
\param  NumFilesNumber of SDL_RWops
\param  argsSDL_RWops for each wsa-File should be in this va_list. 
(can be readonly)
*/
void Wsafile::readdata(int NumFiles, va_list args) {
unsigned char** Filedata;
Uint32** Index;
Uint16* NumberOfFrames;
bool* extended;

if((Filedata = (unsigned char**) malloc(sizeof(unsigned char*) * NumFiles)) 
== NULL) {
fprintf(stderr, "Wsafile::readdata(): Unable to allocate memory!\n");
exit(EXIT_FAILURE);
}

..

   int WsaFilesize;
RWop = va_arg(args,SDL_RWops*);   
Filedata[i] = readfile(RWop,&WsaFilesize); <--- here crash, when not 
the 1. method is called
before

Bye

GCC 4.7.0 as a AVR cross compiler

[stuart]

Hi,

I am not sure this is the right place to ask this, but how do I get gcc
4.7.0 to compile as a cross compiler for the Atmel AVR series?

The native host is an x86 IA32 box running Slackware, gcc 3.3.6.

I have successfully compiled and installed (in /usr/local/avr) binutils
2.22 and set my path to include the newly compiled binutils
(/usr/local/avr/bin).

I can not seem to get gcc 4.7.0 to compile; it will not complete the
configuration stage complaining about missing packages (GMP, MPFR and
MPC). I have tried to cross compile these packages for the Atmel AVR
Mega series but the only one that seems to complete is the GMP
package. The cross compile did produce a lib file (and install it and
the gpm.h file in the correct place) but nothing else would accept that
GMP was present on the system.

I would like to ask the maintainer or tester of the AVR code to include
some notes on cross compiling GCC in future.

Any advice on how to get gcc installed as a cross compiler would be
most welcome.

TIA,
-- 
Stuart
Microsoft - products from convicted criminals

lrzip: extreme compression (but beware its slow decompression speed)

[Jim Meyering]

In case you're evaluating what compression programs to use...

This started off as a comparison of xz and lzip,
but then I added lzrip to the mix.

Sometimes it's useful to have an idea of how far from "ideal"
a compression program is.  I'm not claiming to have the answer,
but merely sharing my surprise at how far off xz and lzip are
when it comes to the size of the compressed result.

I started off by downloading the gcc-4.7.0.tar.bz2 release tarball
and decompressing it, then recompressing using bzip2, lzip, xz and lrzip:
(on a 6/12-core Fedora 17 x86_64 system with plenty of RAM)

  KiB   compression
 size   time m:ss  file name
--     -
514400 NA  gcc-4.7.0.tar
 80588  0:58.12gcc-4.7.0.tar.bz2 (-9)
 59556  6:16.61gcc-4.7.0.tar.lz (-9)
 58640  5:55.78gcc-4.7.0.tar.xz (-9e)
 48876  2:46[*]gcc-4.7.0.tar.lrz (-z -L8 -w2000)

[*] multi-threaded; I think it had at least 6 or 7 cores busy at one point.
This is using the latest, v0.47-590-ga9ba55f, from the upstream repo,
git://github.com/ckolivas/lrzip.git

The above shows that xz compresses both faster (by 5%)
and better (by 916 KiB, or ~1.5%).

It also shows that lrzip compresses extremely well, saving over 9MiB
(aka more than 16%) over xz with its -9e options.


More importantly, what about decompression speed?
The compression happens relatively rarely, by the person who prepares
a release, but then many people download and decompress the result.

(the following xz and lzip times are each best-of-3)

$ env time xz -dc gcc-4.7.0.tar.xz > /dev/null
4.35

$ env time --f=%e lzip -dc gcc-4.7.0.tar.lz > /dev/null
6.06

$ env time --f=%e bzip2 -dc gcc-4.7.0.tar.bz2 > /dev/null
13.96

$ ./lrzip -d -o - gcc-4.7.0.tar.lrz > /dev/null
3:36.12 (note, that's 3.5 *minutes* to decompress on a 12-core system)

That shows another reason to prefer xz over lzip.
xz decompresses this tarball in 28% less time than lzip.

Re: Proposed plugin API for GCC

[Romain Geissler]

Le 30 mars 2012 à 15:48, Ian Lance Taylor a écrit :

> Romain Geissler  writes:
> 
>> Using structs with some sets of function pointers may break compatibility
>> between minor release.
> 
> Yes, but fortunately we have a good understanding of how not to do that.
> 
> We could also go the even safer route used for linker plugins, in which
> the plugin is invoked with a list of functions, where each function is
> tagged with a code.  See include/plugin-api.h for the interface and
> lto-plugin for an implementation.  The approach there is very clean and
> permits forward and backward binary compatibility.  I don't know if we
> want to go that far for compiler plugins.
> 
> 
>> Anyway, you're suggestion to group functions in common names, that's just
>> C++ motto. May the eventual plugin API in C++ (independently from internals
>> being C++ or not) ?
> 
> I think we have a clear understanding of how to maintain compatibility
> across releases in C.  I do not think we have that understanding in C++.
> 
> Ian

Ok thank you, i didn't know about that. I'll take a look to the lto-plugin.

Re: GCC 4.7.0 as a AVR cross compiler

[Ian Lance Taylor]

stuart  writes:

> I am not sure this is the right place to ask this

It's not.  The right place is gcc-h...@gcc.gnu.org.  Please take any
followups there.  Thanks.


> I can not seem to get gcc 4.7.0 to compile; it will not complete the
> configuration stage complaining about missing packages (GMP, MPFR and
> MPC). I have tried to cross compile these packages for the Atmel AVR
> Mega series but the only one that seems to complete is the GMP
> package. The cross compile did produce a lib file (and install it and
> the gpm.h file in the correct place) but nothing else would accept that
> GMP was present on the system.

You need to have GMP, MPFR, and MPC for the host.  You do not need to
cross-compile them for AVR.

Ian

gcc-4.6-20120330 is now available

[gccadmin]

Snapshot gcc-4.6-20120330 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120330/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch 
revision 186028

You'll find:

 gcc-4.6-20120330.tar.bz2 Complete GCC

  MD5=d2f3a090d6e281be978818f314d96a1f
  SHA1=f6dcf50e50434abc685177fe4c52bbcedd239637

Diffs from 4.6-20120323 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Proposed plugin API for GCC

[David Malcolm]

On Fri, 2012-03-30 at 09:05 +0900, Miles Bader wrote:
> David Malcolm  writes:
> > I initially attempted an underscore_based_naming_convention but quickly
> > found it difficult to get concise function names, so I switched to a
> > CamelCaseBased_NamingConvention with an underscore separating a notional
> > namespace element from a secondary element, which saved plenty of space.
> 
> Just use the same names, but with underscore separated (lowercase) words
> instead of StuDLyCapS; obviously they won't be significantly longer, but
> will maintain gcc naming conventions, and will more readable.
Beauty is in the eye of the beholder, I guess.  I greatly prefer
CamelCase, but it's clear that I'm in the minority here.

I'll assume that it can be fixed using sed at some point; how we spell
the API is a minor surface detail compared to much deeper issues like
lifetimes/ownership of objects, the scope of the API, stability
guarantees or lack thereof etc

Re: Proposed plugin API for GCC

[David Malcolm]

On Fri, 2012-03-30 at 14:14 +0200, Richard Guenther wrote:
> On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm  wrote:
> > I had a go at writing a possible plugin API for GCC, and porting parts
> > of my python plugin to it:
> > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e
> >
> > It's very much at the "crude early prototype" stage - all I've wrapped
> > is part of CFG-handling - but the important thing is that python plugin
> > *does* actually compile against this, and many of its selftests still
> > pass (though I'm breaking the self-imposed encapsulation in quite a few
> > places in order to get it to compile).
> >
> > The code is currently jointly owned by me and Red Hat; I'm sure we can
> > do copyright assignment if/when it comes to that.
> >
> > You can see the work-in-progress in the "proposed-plugin-api" branch of
> > gcc-python-plugin.
> >
> > For example, the proposed public header file looks like this:
> > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=proposed-plugin-api/gcc-cfg.h;h=8dbeed0a6c5eb14b0336e89493746887c3bec20a;hb=36a0d6a45473c39db550915f8419a794f2f5653e
> >
> > For example, some design notes can be seen at:
> > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=proposed-plugin-api/design.rst;h=31b960ccac2dcf4d007701b5e9c6556e68e0d107;hb=36a0d6a45473c39db550915f8419a794f2f5653e
> >
> > How do other plugin authors feel about the API?
> 
> Of course I don't like the CamelCasing ;)
Seems like I'm the only person who does around here :)

> The important part of the API is that it exposes no data structures and
> all object references we expose are opaque.
Right.  There's a slight leak in gcc-semiprivate-types.h, but it's all
clearly marked as private (I've seen information hiding where the inner
pointers are all (void*) which sucks when you have to try and debug the
resulting code: it's bad if the information-hiding approach manages to
also hide things from the debugger!)

> You have mostly wrapped in an iterator-style way, I suppose that's fine.
> That (and the CamelCasing) exposes that using a different language for
> this API would be desired; use namespaces to avoid CamelCasing and
> STL style iterators / functors for the rest.  If you stay with C rather
> than using callbacks I would use an explicit iterator representation,
> similar to how we have that now with gimple_stmt_iterator.  Of course
> that's personal preference, subject to bikeshedding.
That raises fun issues like: can the thing be changed during an
iteration?

> Would the python plugin have any issue with using C++?
I have a dislike for it, and will involve a little extra coding, but if
C++ is what it will take to get me a stable API that I can code to
(ideally with some kind of ABI guarantee), that seems a price worth
paying.

I don't know how other plugin authors feel (and I'm keen on hearing if
they think my proposed API could work for them - modulo CamelCase, of
course!).

It's also possible to create a C wrapping around a C++ API and all kinds
of other shenanigans (my Python code is already a wrapper around a
wrapper, so yay, another level of indirection...)

> > How do GCC subsystem maintainers feel?
> 
> Well, positive!  Thanks for starting.  CFG introspection is indeed one
> of the most important parts, then callgraph and statement introspection.
> 
> > I initially attempted an underscore_based_naming_convention but quickly
> > found it difficult to get concise function names, so I switched to a
> > CamelCaseBased_NamingConvention with an underscore separating a notional
> > namespace element from a secondary element, which saved plenty of space.
> > The different naming convention also serves to highlight that this is
> > *not* part of GCC's internals.
> >
> > Hope this is constructive
> 
> Indeed, and thank you for that.
> 
> Btw, how ugly is it to make this API grokable by swig?  Would that serve
> the python plugin?
Why SWIG btw?   I happen to have an intense loathing of SWIG (sorry SWIG
maintainers): in my experience it gives ugly APIs that suffer from
memory leaks, and you end up having to do pointer management in Python,
without the typesafety that a C compiler would give you.  FWIW, Cython
is my wrapper-generator tool of choice, though that's for Python only.
I may be biased, of course!.

Would it be better to work from a higher-level representation of the API
(e.g. XML, or some microformat?) and autogenerate the headers and source
(and docs)?  For the first iteration I wanted to keep things simple,
hence I directly wrote code, rather than code-that-writes-code.

Dave

Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Romain Geissler]

Le 30 mars 2012 à 11:40, Basile Starynkevitch a écrit :

> Hello
> 
> If you want to help me on the makefile issues for the next MELT plugin
> release 0.9.5, please extract the MELT plugin from the svn repository, since
> I am making small changes (which still don't work) since 0.9.5rc1
> 
> The procedure to extract the MELT plugin from the MELT brannch is:
> 
> Retrieve the MELT branch if you don't have it
> 
>   svn co svn://gcc.gnu.org/svn/gcc/branches/melt-branch gcc-melt
> 
> Go into it
> 
>   cd gcc-melt
> 
> Run the update to be sure to have the latest SVN & to gernerate the REVISION
> etc files
> 
>   ./contrib/gcc_update
> 
> Run the following script to get the MELT plugin tarball
> 
>   ./contrib/make-melt-source-tar.sh $PWD /tmp/meltplugin
> 
> You now should have a /tmp/meltplugin.tar.gz which is the MELT plugin
> tarball corresponding to your state of the MELT branch
> 
> Regards.
> -- 
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
> 

Hi,

I tried to build the latest melt-branch (not the generated tarball) on a mac.
Here is the few change required to allow the build (note that it builds but as 
your
cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't 
be
loaded with gcc build with cxx).

I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this
makes no sense to test the availability of the poll function that way : just use
the function, the compiler will find it out by itself if it is really defined. 
Moreover,
this kind of test should be in a configure file, not in a source file. On a mac,
_POSIX_C_SOURCE is not defined by default, and defining it lead to errors
while building other parts of GCC.

Romain Geissler



melt-mac-build.Changelog
Description: Binary data


melt-mac-build.diff
Description: Binary data

Re: Proposed plugin API for GCC

[David Malcolm]

On Fri, 2012-03-30 at 15:08 +0200, Basile Starynkevitch wrote:
> On Fri, Mar 30, 2012 at 02:14:31PM +0200, Richard Guenther wrote:
> > 
> > Btw, how ugly is it to make this API grokable by swig?  Would that serve
> > the python plugin?
> 
> 
> An alternative would be to have either some easily parsable API definition
> (wwhich might be sort-of offered by Swig, but I'll bet that not in practice:
> we'll need to use weird Swig tricks), or some way of querying at runtime that 
> API.
> 
> The important part in my view is that such an API should not be targeted to
> Python only. It should be usable by plugins coded in C++ (or in MELT), or in
> other languages.
> 
> Again, the GTK guys did a good work with their Gobject introspection layer,
> which is a meta-API providing that.

[I briefly worked on the Python 3 backend for GObject introspection,
fwiw]

Here's another proposal then: actually use GObject introspection -
provide a GObject-based API to GCC.

In this approach, GCC would gain a dependency on glib and gobject, and
expose its API via a .gir file.

Thanks to the existing backends, the API would then be immediately
available to Guile, Python 2 and 3, JavaScript, Ruby, etc (and my plugin
either needs a total rewrite, or becomes redundant, disappearing in a
libffi haze...).

For more information, see:
  https://live.gnome.org/GObjectIntrospection

This may be overkill, and the above has the warning "Note: GObject
Introspection is still in development" (I've spent far too long
debugging libffi crashes - due to bogus type signatures - in other
projects to be keen on it, fwiw).

> The point is that GCC will stay complex, and any API will by necessity be
> huge. We have to know that and to ease it uses (e.g. to facilitate the
> embedding of several scripting languages, not only Python).
> 
> So it really would help if the API is documented and mechanically queryable.
> 
> A traditional manual glue code is not enough.
> 
> (And there might be memory management issue; we have to specify very well
> when a GCC data should be released, and by whom. I feel that Ggc is part of
> the solution).
Object lifetimes could be a nuisance: GObjects are reference-counted
iirc.  I don't know if that would be a problem for MELT.

Dave

Re: gcc extensibility

[Miles Bader]

Bernd Schmidt  writes:
>> No, that means would be using the old tool named 'patch' before building
>> GCC.
>
> Or even the new tool named 'git'.

[... and note that "git apply" doesn't actually require a git repo,
and is a great (generally rather better behaved) replacement for the
"patch" command.]

-miles

-- 
Youth, n. The Period of Possibility, when Archimedes finds a fulcrum,
Cassandra has a following and seven cities compete for the honor of endowing a
living Homer.

Re: Proposed plugin API for GCC

[Gabriel Dos Reis]

On Fri, Mar 30, 2012 at 7:45 PM, David Malcolm  wrote:

> Here's another proposal then: actually use GObject introspection -
> provide a GObject-based API to GCC.
>
> In this approach, GCC would gain a dependency on glib and gobject, and
> expose its API via a .gir file.

I greatly prefer the other alternative, by far.

-- Gaby

Why can't copy renaming capture this assignment?

[Jiangning Liu]

Hi,

For this small case, 

char garr[100];
void f(void)
{
unsigned short h, s;

s = 20;

for (h = 1; h < (s-1); h++)
{
garr[h] = 0;
}
}

After copyrename3, we have the following dump,

f ()
{
  short unsigned int h;
  int D.4066;

:
  D.4066_14 = 1;
  if (D.4066_14 <= 18)
goto ;
  else
goto ;

:
  # h_15 = PHI 
  # D.4066_16 = PHI 
  garr[D.4066_16] = 0;
  h_8 = h_15 + 1;
  D.4066_4 = (int) h_8;
  if (D.4066_4 <= 18)
goto ;
  else
goto ;

:
  return;

}

copy renaming fails to capture the assignment statement "D.4066_4 = (int)
h_8;" to trigger renaming partition coalesce. 

I find gimple_assign_single_p invoked by gimple_assign_ssa_name_copy_p
always returns false, because for this statement " gs->gsbase.subcode" is
NOP_EXPR rather than GIMPLE_SINGLE_RHS.

Should subcode be correctly initialized anywhere to fix this problem?

BTW, my expectation after copy renaming is like below, 

f ()
{
  int D.4679;

:
  D.4679_7 = 1;
  if (D.4679_7 != 19)
goto ;
  else
goto ;

:
  # D.4679_15 = PHI 
  # D.4679_17 = PHI 
  garr[D.4679_15] = 0;
  D.4679_14 = D.4679_17 + 1;
  D.4679_4 = D.4679_14;
  if (D.4679_4 != 19)
goto ;
  else
goto ;

:
  return;

}

and then PRE can finally remove that redundancy for symbol D. away.

Thanks,
-Jiangning