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

[Stephan Bergmann]

Hi all,

In LibreOffice's ever-beloved low-level code to synthesize calls to C++ 
virtual functions, I'm having the following problem (on Linux x86_64). 
The function callVirtualMethod at 
 
effectively does the following:


First, call dummy_can_throw_anything that can potentially throw (see 
below for why that's there).  Second, in an asm block, call some virtual 
function (that can potentially throw).  Third, call x86_64::fill_struct 
that can potentially throw (it doesn't, but nobody bothered to annotate 
it as "throw ()").


Now, at least GCC 4.7.0 with -O0 produces a .gcc_except_table section 
for callVirtualMethod, with two call-site table entries each spanning 
the first (dummy_can_throw_anything) and third (x86_64::fill_struct) 
calls, resp., but none spanning the second (asm block) call.  These 
entries are effectively nop, simply calling back into _Unwind_Resume, 
and compiling at higher optimization levels leaves them out anyway 
(leading to callVirtualMethod having no corresponding .gcc_except_table 
section).


The problem is that if the virtual function called through the asm block 
throws an exception, that then immediately leads to std::terminate.  My 
understanding is that because the ip is at the call instruction in the 
asm block that is between the two call-site table entries, the unwind 
machinery thinks this cannot happen and bails out.  (When compiled -O2, 
the code happens to work fine, as there is no .gcc_except_table section 
for this frame at all, so unwinding simply passes through it without 
calling the personality function.)


Making sure that there are no calls to (compiler-visible) functions that 
can throw within callVirtualMethod would happen to make the code also 
work with -O0.  But that would remain a fragile solution.


Is there a way to let the compiler know that the asm block potentially 
calls functions that can throw?  So that it could emit correct code, 
regardless of whether callVirtualMethod happens to have a corresponding 
.gcc_except_table section or not.


(The call to dummy_can_throw_anything, copied from the corresponding 
older code for 32-bit x86, is there for the following reason:  At least 
with some compiler version and some optimization level, on x86 it was 
discovered that the compiler did not emit the .eh_frame data necessary 
for unwinding to successfully pass through this frame at all.  As the 
corresponding x86 code does not have a call to x86_64::fill_struct, the 
compiler apparently considered callVirtualMethod a leaf function and 
optimized accordingly.  The dummy_can_throw_anything hack happened to 
make it do the right thing again, but again this is a fragile solution, 
anyway, that could be replaced with something robust if there were a way 
to annotate the asm block as "calls functions that can throw.")


Stephan

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

[Jakub Jelinek]

On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:
> In LibreOffice's ever-beloved low-level code to synthesize calls to
> C++ virtual functions, I'm having the following problem (on Linux
> x86_64). The function callVirtualMethod at 
> 
> effectively does the following:
> 
> First, call dummy_can_throw_anything that can potentially throw (see
> below for why that's there).  Second, in an asm block, call some
> virtual function (that can potentially throw).  Third, call
> x86_64::fill_struct that can potentially throw (it doesn't, but
> nobody bothered to annotate it as "throw ()").

If the asm isn't in headers, but just in a single short source file
or two, you could try compiling that file with -fnon-call-exceptions.
It is nothing I'd recommend for the whole codebase though.

Jakub

gcc 4.7: -march=corei7-avx bug?

[Dâniel Fraga]

I tried to compile Firefox 11 with gcc 4.7 optimized with:

-O3 -march=corei7-avx (I have a core i7 2700k)

But Firefox segfaults (backtrace provided, although it seems
not very useful):

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762

If I compile with -march=corei7 it runs perfectly.

Maybe a gcc bug?

How can I help you to debug this?

Thanks!

-- 
Linux 3.3.0: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

[ANN] StarPU 1.0.0, hybrid CPU/GPU task programming

[Ludovic Courtès]

We are pleased to announce StarPU 1.0.0, a GCC extension and run-time
support library for hybrid CPU/GPU task programming, available from the
following sites:

  https://gforge.inria.fr/frs/?group_id=1570
  http://runtime.bordeaux.inria.fr/StarPU/files/

Home page:

  http://runtime.bordeaux.inria.fr/StarPU/

StarPU’s GCC plug-in allows programmers to annotate C code to describe
tasks and their implementations, as well as memory buffers that are
passed to the tasks.  Each task may have one or more implementations,
such as CPU implementations or implementations written in OpenCL.  Task
invocations are asynchronous and may be scheduled on any available
matching processing units.

StarPU’s run-time support library schedules tasks over the available CPU
cores and GPUs, and is also responsible for scheduling any data
transfers between main memory and GPUs.

Documentation for the GCC plug-in can be browsed at:

  http://runtime.bordeaux.inria.fr/StarPU/starpu.html#C-Extensions

The plug-in comes with an extensive test suite, and is continuously
tested against released versions of GCC 4.5, 4.6, and 4.7:

  http://hydra.bordeaux.inria.fr/jobset/runtime/starpu-trunk

Please send feedback and bug reports to starpu-de...@lists.gforge.inria.fr!

Ludovic, on behalf the StarPU team.


pgpXPP8Z55IIc.pgp
Description: PGP signature

Re: gcc 4.7: -march=corei7-avx bug?

[Jakub Jelinek]

On Thu, Mar 29, 2012 at 04:53:45AM -0300, Dâniel Fraga wrote:
>   I tried to compile Firefox 11 with gcc 4.7 optimized with:
> 
> -O3 -march=corei7-avx (I have a core i7 2700k)
> 
>   But Firefox segfaults (backtrace provided, although it seems
> not very useful):
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762
> 
>   If I compile with -march=corei7 it runs perfectly.
> 
>   Maybe a gcc bug?

Maybe.  Or maybe firefox bug.

>   How can I help you to debug this?

Build with debug info, try to understand why it crashed, build
a minimal testcase out of it, attach it to the PR.
Or you could use a brute force method, if -march=corei7 works,
but -march=corei7-avx doesn't, do a binary search on firefox built with
some corei7 and some corei7-avx object files, until you find the problematic
compilation unit.

Jakub

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

[Stephan Bergmann]

On 03/29/2012 09:44 AM, Jakub Jelinek wrote:

On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:

In LibreOffice's ever-beloved low-level code to synthesize calls to
C++ virtual functions, I'm having the following problem (on Linux
x86_64). The function callVirtualMethod 
at
effectively does the following:

First, call dummy_can_throw_anything that can potentially throw (see
below for why that's there).  Second, in an asm block, call some
virtual function (that can potentially throw).  Third, call
x86_64::fill_struct that can potentially throw (it doesn't, but
nobody bothered to annotate it as "throw ()").


If the asm isn't in headers, but just in a single short source file
or two, you could try compiling that file with -fnon-call-exceptions.
It is nothing I'd recommend for the whole codebase though.


Turns out I had to move the callVirtualMethod function containing the 
asm into a source file of its own, anyway.  (Otherwise, even if it no 
longer explicitly called functions that can throw, and thus no longer 
had corresponding .gcc_except_table entries, exception throwing still 
lead to std::terminate.  There are other functions in the same source 
file callVirtualMethod was originally in that do have .gcc_except_table 
entries.  Kind of invalidates my previous explanation of why exception 
handling bailed out to std::terminate.  Looks like I haven't groked it 
yet, anyway.)


So an explicit -fnon-call-exceptions on the command line seems to indeed 
help.  Unfortunately, moving that into a


  #pragma GCC optimize ("non-call-exceptions")

at the top of the source file that defines callVirtualMethod (and 
nothing more) does *not* work.  Is that a bug?


Anyway, would it be worthwhile filing an RFE for an asm annotation 
telling the compiler that it contains code that can throw?


Thanks,
Stephan

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

[Richard Guenther]

On Thu, Mar 29, 2012 at 10:47 AM, Stephan Bergmann  wrote:
> On 03/29/2012 09:44 AM, Jakub Jelinek wrote:
>>
>> On Thu, Mar 29, 2012 at 09:05:29AM +0200, Stephan Bergmann wrote:
>>>
>>> In LibreOffice's ever-beloved low-level code to synthesize calls to
>>> C++ virtual functions, I'm having the following problem (on Linux
>>> x86_64). The function callVirtualMethod
>>> at
>>> effectively does the following:
>>>
>>> First, call dummy_can_throw_anything that can potentially throw (see
>>> below for why that's there).  Second, in an asm block, call some
>>> virtual function (that can potentially throw).  Third, call
>>> x86_64::fill_struct that can potentially throw (it doesn't, but
>>> nobody bothered to annotate it as "throw ()").
>>
>>
>> If the asm isn't in headers, but just in a single short source file
>> or two, you could try compiling that file with -fnon-call-exceptions.
>> It is nothing I'd recommend for the whole codebase though.
>
>
> Turns out I had to move the callVirtualMethod function containing the asm
> into a source file of its own, anyway.  (Otherwise, even if it no longer
> explicitly called functions that can throw, and thus no longer had
> corresponding .gcc_except_table entries, exception throwing still lead to
> std::terminate.  There are other functions in the same source file
> callVirtualMethod was originally in that do have .gcc_except_table entries.
>  Kind of invalidates my previous explanation of why exception handling
> bailed out to std::terminate.  Looks like I haven't groked it yet, anyway.)
>
> So an explicit -fnon-call-exceptions on the command line seems to indeed
> help.  Unfortunately, moving that into a
>
>  #pragma GCC optimize ("non-call-exceptions")
>
> at the top of the source file that defines callVirtualMethod (and nothing
> more) does *not* work.  Is that a bug?

The optimize pragma has only very limited support for this kind of options,
so yes, it's techincally a bug but don't hold your breath.

> 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.

Richard.

> Thanks,
> Stephan

Missed optimization in PRE?

[Bin.Cheng]

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 ,
but why not lowered into basic block 3, where it is used.

BTW, seems no tree pass handles this case currently.

Any idea? Thanks

  int z$imag;
  int z$real;
  int D.5378;
  int D.5377;
  int D.5376;
  int D.5375;

:
  D.5375_11 = REALPART_EXPR ;
  D.5376_12 = IMAGPART_EXPR ;
  D.5377_13 = REALPART_EXPR ;
  D.5378_14 = IMAGPART_EXPR ;
  if (D.5375_11 == D.5377_13)
goto ;
  else
goto ;

:
  if (D.5376_12 == D.5378_14)
goto ;
  else
goto ;

:
  z$real_15 = REALPART_EXPR ;
  z$imag_16 = IMAGPART_EXPR ;
  goto ;

:

:
  z$real_17 = REALPART_EXPR ;
  z$imag_18 = IMAGPART_EXPR ;

:
  # z$real_19 = PHI 
  # z$imag_20 = PHI 
  REALPART_EXPR  = z$real_19;
  IMAGPART_EXPR  = z$imag_20;
  return 0;

-- 
Best Regards.

Re: Missed optimization in PRE?

[Richard Guenther]

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.

> Any idea? Thanks
>
>  int z$imag;
>  int z$real;
>  int D.5378;
>  int D.5377;
>  int D.5376;
>  int D.5375;
>
> :
>  D.5375_11 = REALPART_EXPR ;
>  D.5376_12 = IMAGPART_EXPR ;
>  D.5377_13 = REALPART_EXPR ;
>  D.5378_14 = IMAGPART_EXPR ;
>  if (D.5375_11 == D.5377_13)
>    goto ;
>  else
>    goto ;
>
> :
>  if (D.5376_12 == D.5378_14)
>    goto ;
>  else
>    goto ;
>
> :
>  z$real_15 = REALPART_EXPR ;
>  z$imag_16 = IMAGPART_EXPR ;
>  goto ;
>
> :
>
> :
>  z$real_17 = REALPART_EXPR ;
>  z$imag_18 = IMAGPART_EXPR ;
>
> :
>  # z$real_19 = PHI 
>  # z$imag_20 = PHI 
>  REALPART_EXPR  = z$real_19;
>  IMAGPART_EXPR  = z$imag_20;
>  return 0;
>
> --
> Best Regards.

Re: Missed optimization in PRE?

[Bin.Cheng]

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.

-- 
Best Regards.

Re: Missed optimization in PRE?

[Richard Guenther]

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.

Richard.

> --
> Best Regards.

Re: Missed optimization in PRE?

[Bin.Cheng]

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.
>
ok, I will investigate it.


-- 
Best Regards.

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[David Brown]

On 29/03/2012 00:52, mathog wrote:

On 28-Mar-2012 15:20, Michael Witten wrote:


However, it seems to me that toggling the value with the idiom:

--b;

is aesthetically preferable to the more elaborate:

b = !b;


Aesthetically, not logically. Neither of these makes the least bit of
sense:

one less than False
one less than True

A better solution for the aesthetics would have been (it is a bit late
now) to implement the missing unary negation operator:

!!b; //T->F, F->T



You can't do that, because "!!" is already a useful operator on integers 
- it turns anything non-zero into 1 while leaving 0 alone, and is 
effectively an "int to bool" conversion operator.



That operator would save even more program characters for the other int
types, where it would be equivalent to:

(i==0 ? 1 : 0);


Regards,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

gcc extensibility

[Niels Möller]

I originally wrote this email as a reply to Ian Lance Taylor on a
different list, and he suggested that I send it also to the gcc list.
Please cc me on replies, since I'm not subscribed to the list. I hope
I'm not being too off-topic or off-the-mark.

Let me write down some reflections on gcc extensibility, even if I'm not
familiar at all with gcc internals.

1. I imagine the plugin API ought to stay in plain C, right?

2. Then there are at least two ways to think about the plugin API to,
   e.g., the gcc tree abstraction.

   Either one can define a C API one think the plugins will like, and
   then implement that on top of the internal C++ interfaces. These will
   be small wrapper functions, which lets the internal interfaces evolve
   without affecting the plugins.

   Or one sticks to a single "unified" tree API, to be used *both*
   internally and by plugins.

   I suspect the second option is the right one, because it brings some
   equality between plugin authors and gcc developers. It should make it
   easier to adopt a plugin into gcc proper. Together with (1), this
   forces the internal interface to be C rather than C++, which I guess
   you may see as a serious disadvantage.

   Going for a unified API, one gets less independence between plugins
   and gcc internals, but in return, one gets less clutter, and I think
   it may improve quality. Otherwise, it seems likely that one ends up
   with an internal interface which is powerful but somewhat ugly
   (internal use only, right?) and an external interface which may be
   beautiful on the surface, but in practice it's a second class citizen
   and awkward for doing interesting things with.

3. What is the purpose of the plugin API? I can see that it should make
   it easier to prototype new optimization passes. Both for educational
   purposes, and research, as well as by the gcc developers themselves.

   One of the goals you stated was "I think parts of GCC needs to move
   toward being a component of tools other than pure compilation, such
   as refactoring, profile analysis, debugging."

   I think we can all agree that's highly desirable. To be more
   concrete, I think it would be useful have access to information from
   the parse tree, from the symbol table (both for compiler and linker),
   dataflow analysis, etc, when editing C code in emacs. Is a plugin API
   the right tool for that type of integration? Or should one also have
   a gcc library, and have various other specialized tools link to that
   library?

   Maybe the organization of valgrind could provide some inspiration,
   with a couple of different tools on top of the same machinery.

Happy hacking,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

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

[Stephan Bergmann]

On 03/29/2012 11:16 AM, Richard Guenther wrote:

On Thu, Mar 29, 2012 at 10:47 AM, Stephan Bergmann  wrote:

So an explicit -fnon-call-exceptions on the command line seems to indeed
help.  Unfortunately, moving that into a

  #pragma GCC optimize ("non-call-exceptions")

at the top of the source file that defines callVirtualMethod (and nothing
more) does *not* work.  Is that a bug?


The optimize pragma has only very limited support for this kind of options,
so yes, it's techincally a bug but don't hold your breath.


OK.  (It's just that the way LibreOffice is build, its a PITA to compile 
a single file with differing options...)



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."


Thanks,
Stephan

Re: gcc extensibility

[Richard Guenther]

On Thu, Mar 29, 2012 at 2:34 PM, Niels Möller  wrote:
> I originally wrote this email as a reply to Ian Lance Taylor on a
> different list, and he suggested that I send it also to the gcc list.
> Please cc me on replies, since I'm not subscribed to the list. I hope
> I'm not being too off-topic or off-the-mark.
>
> Let me write down some reflections on gcc extensibility, even if I'm not
> familiar at all with gcc internals.
>
> 1. I imagine the plugin API ought to stay in plain C, right?
>
> 2. Then there are at least two ways to think about the plugin API to,
>   e.g., the gcc tree abstraction.
>
>   Either one can define a C API one think the plugins will like, and
>   then implement that on top of the internal C++ interfaces. These will
>   be small wrapper functions, which lets the internal interfaces evolve
>   without affecting the plugins.
>
>   Or one sticks to a single "unified" tree API, to be used *both*
>   internally and by plugins.
>
>   I suspect the second option is the right one, because it brings some
>   equality between plugin authors and gcc developers. It should make it
>   easier to adopt a plugin into gcc proper. Together with (1), this
>   forces the internal interface to be C rather than C++, which I guess
>   you may see as a serious disadvantage.

On the contrary - I think the first option is the right one.  Only that way
we can provide a stable ABI towards plugins.

>   Going for a unified API, one gets less independence between plugins
>   and gcc internals, but in return, one gets less clutter, and I think
>   it may improve quality. Otherwise, it seems likely that one ends up
>   with an internal interface which is powerful but somewhat ugly
>   (internal use only, right?) and an external interface which may be
>   beautiful on the surface, but in practice it's a second class citizen
>   and awkward for doing interesting things with.

It really depends on what plugins should be doing.  Or rather what
most plugins will end up doing.  In the end we probably will end up
with a stable plugin API/ABI for that common case (introspection
and simple instrumentation) and the awkward current one exporting
every GCC internal.

> 3. What is the purpose of the plugin API? I can see that it should make
>   it easier to prototype new optimization passes. Both for educational
>   purposes, and research, as well as by the gcc developers themselves.

No.  That's way easier to do if you are _not_ a plugin.

>   One of the goals you stated was "I think parts of GCC needs to move
>   toward being a component of tools other than pure compilation, such
>   as refactoring, profile analysis, debugging."

Right, and I see primarily those uses.

Richard.

>   I think we can all agree that's highly desirable. To be more
>   concrete, I think it would be useful have access to information from
>   the parse tree, from the symbol table (both for compiler and linker),
>   dataflow analysis, etc, when editing C code in emacs. Is a plugin API
>   the right tool for that type of integration? Or should one also have
>   a gcc library, and have various other specialized tools link to that
>   library?
>
>   Maybe the organization of valgrind could provide some inspiration,
>   with a couple of different tools on top of the same machinery.
>
> Happy hacking,
> /Niels
>
> --
> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
> Internet email is subject to wholesale government surveillance.
>

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

[Michael Matz]

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
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;
 

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

[Andrew Haley]

On 03/29/2012 02:59 PM, Michael Matz wrote:
> 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 (...)" ?

Is there any point?  I would have thought that -fnon-call-exceptions was
exactly what you need.

Andrew.

unwind and type support in GCC47

[Paulo J. Matos]

Hi,

I am porting my backend to GCC47 and have been jumping through some 
hurdles. libgcc is trying to compile unwind*.c files which I can't 
remember being there for GCC46. I deduce this files have to do with 
exception support GCC47 seems to want to make exceptions mandatory even 
though my backend doesn't really 'support' them (in the sense that our 
tests don't care about them).

unwind*.c have a lot of variable definitions to mode SI as being a word, 
However, in my case a word is actually in mode QI (16bits). Is there 
anything I can do to stop libgcc from trying to compile these files or to 
make unwind compatible with my backend besides going blindly changing SI 
mode in variable declaration to QI mode?

Cheers,
-- 
PMatos

Re: Backends with no exception handling on GCC47

[Paulo J. Matos]

On Mon, 26 Mar 2012 11:10:11 -0700, Ian Lance Taylor wrote:

> 
>> *** Configuration xap-local-xap not supported
> 
> You will have to find out where that last error message is coming from.
> It's not happening because of errors in configure tests.  It's most
> likely coming from libgcc/config.host.  You probably need to add an
> entry for xap-*-* in that switch.
> 
> Since you are porting to GCC 4.7, probably you need to move some support
> from gcc/config/zap over to libgcc/config/xap.  In GCC 4.7 there has
> been a lot of work to move target library code from gcc to libgcc.
> 

Thanks, it was indeed that. I didn't have support my backend in libgcc/
config.host.
Is there anything documenting porting backend between GCC major versions 
(GCC4.6 - GCC4.7), in order to avoid these questions?

Thanks,

-- 
PMatos

Re: gcc extensibility

[Gabriel Dos Reis]

On Thu, Mar 29, 2012 at 7:34 AM, Niels Möller  wrote:

> 1. I imagine the plugin API ought to stay in plain C, right?
>
> 2. Then there are at least two ways to think about the plugin API to,
>   e.g., the gcc tree abstraction.
>
>   Either one can define a C API one think the plugins will like, and
>   then implement that on top of the internal C++ interfaces. These will
>   be small wrapper functions, which lets the internal interfaces evolve
>   without affecting the plugins.
>
>   Or one sticks to a single "unified" tree API, to be used *both*
>   internally and by plugins.
>
>   I suspect the second option is the right one, because it brings some
>   equality between plugin authors and gcc developers.

It is a false equality.  The needs of plugins authors are not necessarily
the same as the need of GCC development itself.

You really do not want the existence of plugins to hinder (internal)
evolution of GCC itself.

-- Gaby

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

[Stephan Bergmann]

On 03/29/2012 04:12 PM, Andrew Haley wrote:

On 03/29/2012 02:59 PM, Michael Matz wrote:

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 (...)" ?


Is there any point?  I would have thought that -fnon-call-exceptions was
exactly what you need.


But it looks wrong to me to have to mark the complete compilation unit 
for something that should only affect a single asm declaration.  (Also, 
having to specify -fnon-call-exceptions "externally," on the command 
line, is somewhat awkward.)


Stephan

Re: Missed optimization in PRE?

[Bin.Cheng]

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.


-- 
Best Regards.

Re: gcc extensibility

[Romain Geissler]

Hi

Le 29 mars 2012 à 14:34, Niels Möller a écrit :

> 1. I imagine the plugin API ought to stay in plain C, right?

I don't know if this was already discussed and if the community
ended up with a clear answer for this question. If it's not the case
i would prefer a plugin interface in C++, for the same reasons it
was decided to slowly move the internals to C++.

Romain Geissler

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

[Michael Matz]

Hi,

On Thu, 29 Mar 2012, Andrew Haley wrote:

> On 03/29/2012 02:59 PM, Michael Matz wrote:
> > 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 (...)" ?
> 
> Is there any point?  I would have thought that -fnon-call-exceptions was
> exactly what you need.

non-call-exceptions is a relatively big hammer.  It marks _all_ 
non-trivial instructions as throwing.  Providing an explicit marker would 
allow for more granularity.  Granted, the request didn't come often over 
the last years, but it seems like a relatively self-contained and useful 
addition to inline asms.


Ciao,
Michael.

Re: gcc extensibility

[Gabriel Dos Reis]

On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler
 wrote:
> Hi
>
> Le 29 mars 2012 à 14:34, Niels Möller a écrit :
>
>> 1. I imagine the plugin API ought to stay in plain C, right?
>
> I don't know if this was already discussed and if the community
> ended up with a clear answer for this question. If it's not the case
> i would prefer a plugin interface in C++, for the same reasons it
> was decided to slowly move the internals to C++.
>

I do not think people working on plugins have come up with a
specification and an API they agree on.  Which makes any talk
of restricting GCC's own evolution premature if not pointless.

-- Gaby

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

[Richard Henderson]

On 03/29/2012 03:05 AM, Stephan Bergmann wrote:
> Hi all,
> 
> In LibreOffice's ever-beloved low-level code to synthesize calls to
> C++ virtual functions, I'm having the following problem (on Linux
> x86_64). The function callVirtualMethod at
> 
> effectively does the following:

Quoting:

asm volatile (

// Fill the xmm registers
"movq %6, %%rax\n\t"

"movsd   (%%rax), %%xmm0\n\t"
"movsd  8(%%rax), %%xmm1\n\t"
"movsd 16(%%rax), %%xmm2\n\t"
"movsd 24(%%rax), %%xmm3\n\t"
"movsd 32(%%rax), %%xmm4\n\t"
"movsd 40(%%rax), %%xmm5\n\t"
"movsd 48(%%rax), %%xmm6\n\t"
"movsd 56(%%rax), %%xmm7\n\t"

// Fill the general purpose registers
"movq %5, %%rax\n\t"

"movq(%%rax), %%rdi\n\t"
"movq   8(%%rax), %%rsi\n\t"
"movq  16(%%rax), %%rdx\n\t"
"movq  24(%%rax), %%rcx\n\t"
"movq  32(%%rax), %%r8\n\t"
"movq  40(%%rax), %%r9\n\t"

// Perform the call
"movq %4, %%r11\n\t"
"movq %7, %%rax\n\t"
"call *%%r11\n\t"

// Fill the return values
"movq   %%rax, %0\n\t"
"movq   %%rdx, %1\n\t"
"movsd %%xmm0, %2\n\t"
"movsd %%xmm1, %3\n\t"
: "=m" ( rax ), "=m" ( rdx ), "=m" ( xmm0 ), "=m" ( xmm1 )
: "m" ( pMethod ), "m" ( pGPR ), "m" ( pFPR ), "m" ( nFPR )
: "rax", "rdi", "rsi", "rdx", "rcx", "r8", "r9", "r11"
);

Semi-off-topic, I think this asm can be better done with only the
call inside the asm, and the rest handled by the compiler.

  {
register sal_uInt64 hard_r8 __asm__("rax"); // etc
register double hard_xmm0 __asm__("xmm0"); // etc

hard_rdi = pGPR[0]; //etc
hard_xmm0 = pFPR[0]; //etc
hard_rax = nFPR;

asm volatile ("call *%[method]"
  : "+r"(hard_rax), //etc
"+x"(hard_xmm0), //etc
  : "g" [method] (pMethod)
  : "memory");

rax = hard_rax;
rdx = hard_rdx;
xmm0 = hard_xmm0;
xmm1 = hard_xmm1;
  }


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.


r~

Re: gcc extensibility

[Basile Starynkevitch]

On Thu, 29 Mar 2012 11:06:11 -0500
Gabriel Dos Reis  wrote:

> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler
>  wrote:
> > Hi
> >
> > Le 29 mars 2012 à 14:34, Niels Möller a écrit :
> >
> >> 1. I imagine the plugin API ought to stay in plain C, right?
> >
> > I don't know if this was already discussed and if the community
> > ended up with a clear answer for this question. If it's not the case
> > i would prefer a plugin interface in C++, for the same reasons it
> > was decided to slowly move the internals to C++.
> >
> 
> I do not think people working on plugins have come up with a
> specification and an API they agree on.


I believe plugin makers (if you can count me amongst them) don't have at all 
this
approach. By definition, a plugin should work with whatever interface a given 
GCC release
makes available. Plugins people by definition cannot alter or improve the 
interface that
GCC is giving to them (otherwise, they are no more plugins people, but GCC 
contributors).

What I mean is that it has absolutely no sense to make a plugin for something 
which is
derived from GCC (e.g. for an experimental branch or fork of GCC). The very 
idea of
plugins is that they should work with an unmodified distributed GCC.

To be more concrete, I am right now passing some time to make MELT usable with 
the GCC
4.7 released by Debian/Sid (exactly it), not with the GCC 4.7 I used to build 
myself
(which e.g. was compiled in C mode only).

Plugins don't have much sense if they don't work with widely distributed, but 
recent,
releases of GCC. So plugins people won't propose, as plugins developers, any API
interface to GCC; they will stick to whatever is available to them.

[in other words, I may propose some patch or enhancement to GCC, but then I am 
acting as
a GCC contributor, not as a plugin developer]

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 mine, sont seulement les miennes} ***

Re: gcc extensibility

[Gabriel Dos Reis]

On Thu, Mar 29, 2012 at 11:27 AM, Basile Starynkevitch
 wrote:
> On Thu, 29 Mar 2012 11:06:11 -0500
> Gabriel Dos Reis  wrote:
>
>> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler
>>  wrote:
>> > Hi
>> >
>> > Le 29 mars 2012 à 14:34, Niels Möller a écrit :
>> >
>> >> 1. I imagine the plugin API ought to stay in plain C, right?
>> >
>> > I don't know if this was already discussed and if the community
>> > ended up with a clear answer for this question. If it's not the case
>> > i would prefer a plugin interface in C++, for the same reasons it
>> > was decided to slowly move the internals to C++.
>> >
>>
>> I do not think people working on plugins have come up with a
>> specification and an API they agree on.
>
>
> I believe plugin makers (if you can count me amongst them) don't have at all 
> this
> approach. By definition, a plugin should work with whatever interface a given 
> GCC release
> makes available. Plugins people by definition cannot alter or improve the 
> interface that
> GCC is giving to them (otherwise, they are no more plugins people, but GCC 
> contributors).

I suspect that if plugins people want to make progress on this
recurring theme, they
will have to come up with a specification and an API.  Otherwise, they have only
themselves to blame if their plugins break from release to release.

-- Gaby

Re: gcc extensibility

[Basile Starynkevitch]

On Thu, 29 Mar 2012 11:42:30 -0500
Gabriel Dos Reis  wrote:
> I suspect that if plugins people want to make progress on this
> recurring theme, they
> will have to come up with a specification and an API.  Otherwise, they have 
> only
> themselves to blame if their plugins break from release to release.


They blame nobody if their plugins break from one release to the next. They 
take this
incompatibility of GCC as part of their plugins developer's work.

Again, a plugin writer by definition uses whatever interface is given to him.

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 mine, sont seulement les miennes} ***

Re: gcc extensibility

[Gabriel Dos Reis]

On Thu, Mar 29, 2012 at 11:52 AM, Basile Starynkevitch
 wrote:

> They blame nobody if their plugins break from one release to the next. They 
> take this
> incompatibility of GCC as part of their plugins developer's work.

Great!  Problem solved.

-- Gaby

Re: gcc extensibility

[Andrew MacLeod]

On 03/29/2012 12:52 PM, Basile Starynkevitch wrote:


They blame nobody if their plugins break from one release to the next. They 
take this
incompatibility of GCC as part of their plugins developer's work.

Again, a plugin writer by definition uses whatever interface is given to him.

Cheers.


That doesn't mean a plugin developer can't use their experience and 
offer opinions on what would be a good/better plugin interface.


If the plugin developers could agree on what a better interface would 
be, it would go a long way toward encouraging GCC to provide that interface.


Without such feedback, the status quo is unlikely to change since GCC 
developers don't know what a better interface would be...


Andrew

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

[Jan Hubicka]

> On 03/29/2012 03:05 AM, Stephan Bergmann wrote:
> > Hi all,
> > 
> > In LibreOffice's ever-beloved low-level code to synthesize calls to
> > C++ virtual functions, I'm having the following problem (on Linux
> > x86_64). The function callVirtualMethod at
> > 
> > effectively does the following:
> 
> Quoting:
> 
> asm volatile (
> 
> // Fill the xmm registers
> "movq %6, %%rax\n\t"
> 
> "movsd   (%%rax), %%xmm0\n\t"
> "movsd  8(%%rax), %%xmm1\n\t"
> "movsd 16(%%rax), %%xmm2\n\t"
> "movsd 24(%%rax), %%xmm3\n\t"
> "movsd 32(%%rax), %%xmm4\n\t"
> "movsd 40(%%rax), %%xmm5\n\t"
> "movsd 48(%%rax), %%xmm6\n\t"
> "movsd 56(%%rax), %%xmm7\n\t"
> 
> // Fill the general purpose registers
> "movq %5, %%rax\n\t"
> 
> "movq(%%rax), %%rdi\n\t"
> "movq   8(%%rax), %%rsi\n\t"
> "movq  16(%%rax), %%rdx\n\t"
> "movq  24(%%rax), %%rcx\n\t"
> "movq  32(%%rax), %%r8\n\t"
> "movq  40(%%rax), %%r9\n\t"
> 
> // Perform the call
> "movq %4, %%r11\n\t"
> "movq %7, %%rax\n\t"
> "call *%%r11\n\t"
> 
> // Fill the return values
> "movq   %%rax, %0\n\t"
> "movq   %%rdx, %1\n\t"
> "movsd %%xmm0, %2\n\t"
> "movsd %%xmm1, %3\n\t"
> : "=m" ( rax ), "=m" ( rdx ), "=m" ( xmm0 ), "=m" ( xmm1 )
> : "m" ( pMethod ), "m" ( pGPR ), "m" ( pFPR ), "m" ( nFPR )
> : "rax", "rdi", "rsi", "rdx", "rcx", "r8", "r9", "r11"
> );
> 
> Semi-off-topic, I think this asm can be better done with only the
> call inside the asm, and the rest handled by the compiler.
> 
>   {
> register sal_uInt64 hard_r8 __asm__("rax"); // etc
> register double hard_xmm0 __asm__("xmm0"); // etc
> 
> hard_rdi = pGPR[0]; //etc
> hard_xmm0 = pFPR[0]; //etc
> hard_rax = nFPR;
> 
> asm volatile ("call *%[method]"
>   : "+r"(hard_rax), //etc
> "+x"(hard_xmm0), //etc
>   : "g" [method] (pMethod)
>   : "memory");
> 
> rax = hard_rax;
> rdx = hard_rdx;
> xmm0 = hard_xmm0;
> xmm1 = hard_xmm1;
>   }
> 
> 
> 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. 
Do we prevent code motion of hard registers sets i.e. at GIMPLE level? (I know 
pre-reload
scheduler was improved here, but I would not rely on it either).
As soon as hard_rdi/hard_rax set is moved upwards or downwards across 
memset/division
or other stuff requiring rax or rdx, reload will ICE.

Honza
> 
> 
> r~

Re: gcc extensibility

[Romain Geissler]

Le 29 mars 2012 à 18:06, Gabriel Dos Reis a écrit :

> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler
>  wrote:
>> Hi
>> 
>> Le 29 mars 2012 à 14:34, Niels Möller a écrit :
>> 
>>> 1. I imagine the plugin API ought to stay in plain C, right?
>> 
>> I don't know if this was already discussed and if the community
>> ended up with a clear answer for this question. If it's not the case
>> i would prefer a plugin interface in C++, for the same reasons it
>> was decided to slowly move the internals to C++.
>> 
> 
> I do not think people working on plugins have come up with a
> specification and an API they agree on.  Which makes any talk
> of restricting GCC's own evolution premature if not pointless.

I didn't mean the choice of C or C++ for the future plugin API may
in any way alter the own GCC evolution. The API only consists in
a bunch of stable wrappers to the unstable internals. Once such
an API exists, that won't be hard to update the impacted wrappers
to follow that changes, and thus it would have only minor impact on
the internals evolution.

Re: gcc 4.7: -march=corei7-avx bug?

[Dâniel Fraga]

On Thu, 29 Mar 2012 10:26:47 +0200
Jakub Jelinek  wrote:

> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762

> Build with debug info, try to understand why it crashed, build
> a minimal testcase out of it, attach it to the PR.
> Or you could use a brute force method, if -march=corei7 works,
> but -march=corei7-avx doesn't, do a binary search on firefox built with
> some corei7 and some corei7-avx object files, until you find the problematic
> compilation unit.

Hi Jakub, I posted a new backtrace with --enable-debug to
the above bug report. I hope it helps.

If you need more testing or want em to apply some patch, just
ask. Thanks.

-- 
Linux 3.3.0: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

Re: [bool wrapping] Request for warnings on implicit bool to int conversions

[mathog]

On 29-Mar-2012 03:20, David Brown wrote:

On 29/03/2012 00:52, mathog wrote:


A better solution for the aesthetics would have been (it is a bit 
late

now) to implement the missing unary negation operator:

!!b; //T->F, F->T



You can't do that, because "!!" is already a useful operator on
integers - it turns anything non-zero into 1 while leaving 0 alone,
and is effectively an "int to bool" conversion operator.


Right, hence the "a bit late now".

(I'm going to use "unary operator" for the rest of this to mean 
operations like ++, an operator that
changes the value of the operand all by itself.  There is some other 
technical term to distinguish that
from a unary "-", for instance, but I have long since forgotten what it 
is.)


I understand we aren't likely to ever see !! as a unary operator 
because of backwards
compatibility issues.  Since unary not is an obvious thing to have 
added to C99 along with
bool, my guess is that they couldn't figure a way to squeeze it in 
without stepping on !!

or something else still needed for backwards compatibility.

This highlights the problem with defining unary operators by repetition 
of single characters,
rather than by using a special symbol to indicate all of the unary 
operators, something like


  i@+ , i@- instead of i++, i--
  +@i , -@i instead if ++i, --i

and so forth, which would have allowed for unary variants of more 
operators. Including those not
considered at the time the language was first constructed. Here:  !@b 
and b@!, but also for
~, for instance.  We are all used to "++" now, but if you think about 
it
"add twice" is not a natural synonym for "increment", whereas 
 is.


Anyway, this ship sailed a long, long, long time ago.

Regards,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: gcc extensibility

[Romain Geissler]

Le 29 mars 2012 à 15:14, Richard Guenther a écrit :

> On Thu, Mar 29, 2012 at 2:34 PM, Niels Möller  wrote:
>> I originally wrote this email as a reply to Ian Lance Taylor on a
>> different list, and he suggested that I send it also to the gcc list.
>> Please cc me on replies, since I'm not subscribed to the list. I hope
>> I'm not being too off-topic or off-the-mark.
>> 
>> Let me write down some reflections on gcc extensibility, even if I'm not
>> familiar at all with gcc internals.
>> 
>> 1. I imagine the plugin API ought to stay in plain C, right?
>> 
>> 2. Then there are at least two ways to think about the plugin API to,
>>   e.g., the gcc tree abstraction.
>> 
>>   Either one can define a C API one think the plugins will like, and
>>   then implement that on top of the internal C++ interfaces. These will
>>   be small wrapper functions, which lets the internal interfaces evolve
>>   without affecting the plugins.
>> 
>>   Or one sticks to a single "unified" tree API, to be used *both*
>>   internally and by plugins.
>> 
>>   I suspect the second option is the right one, because it brings some
>>   equality between plugin authors and gcc developers. It should make it
>>   easier to adopt a plugin into gcc proper. Together with (1), this
>>   forces the internal interface to be C rather than C++, which I guess
>>   you may see as a serious disadvantage.
> 
> On the contrary - I think the first option is the right one.  Only that way
> we can provide a stable ABI towards plugins.

I also think that the plugin layer should be as much as possible distinct from
the internals, may some patch break the plugin API for a short period of time
in the trunk, as soon as official releases keep it working well
(as i think plugins must not slow down GCC own evolution).

As plugins are only meant to perform introspection and minor tree 
transformations
they do not need the whole internal API. Such an API also require stability
contrary to internals which may change at any time. 

As a plugin developer, i don't think plugin developers should have
that equality with GCC developers you are worried about.

> 
>>   Going for a unified API, one gets less independence between plugins
>>   and gcc internals, but in return, one gets less clutter, and I think
>>   it may improve quality. Otherwise, it seems likely that one ends up
>>   with an internal interface which is powerful but somewhat ugly
>>   (internal use only, right?) and an external interface which may be
>>   beautiful on the surface, but in practice it's a second class citizen
>>   and awkward for doing interesting things with.
> 
> It really depends on what plugins should be doing.  Or rather what
> most plugins will end up doing.  In the end we probably will end up
> with a stable plugin API/ABI for that common case (introspection
> and simple instrumentation) and the awkward current one exporting
> every GCC internal.
> 
>> 3. What is the purpose of the plugin API? I can see that it should make
>>   it easier to prototype new optimization passes. Both for educational
>>   purposes, and research, as well as by the gcc developers themselves.
> 
> No.  That's way easier to do if you are _not_ a plugin.
> 
>>   One of the goals you stated was "I think parts of GCC needs to move
>>   toward being a component of tools other than pure compilation, such
>>   as refactoring, profile analysis, debugging."
> 
> Right, and I see primarily those uses.
> 
> Richard.

Well currently GCC deeply lacks the structure to break it into distinct
component. I roughly see plugins as a solution in the middle : you keep
the whole gcc in a single block, but still you can perform minor task
on your own by dlopening a plugin.so of your own rather than breaking
gcc in a proper structued libgcc.

Of course, a beautiful defined and structed libgcc would be welcome,
but this would take much more time refactoring the existing code base,
and see, plugins which are only a small part of that work, are already
tough to implement.

Romain Geissler

> 
> 
>>   I think we can all agree that's highly desirable. To be more
>>   concrete, I think it would be useful have access to information from
>>   the parse tree, from the symbol table (both for compiler and linker),
>>   dataflow analysis, etc, when editing C code in emacs. Is a plugin API
>>   the right tool for that type of integration? Or should one also have
>>   a gcc library, and have various other specialized tools link to that
>>   library?
>> 
>>   Maybe the organization of valgrind could provide some inspiration,
>>   with a couple of different tools on top of the same machinery.
>> 
>> Happy hacking,
>> /Niels
>> 
>> --
>> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
>> Internet email is subject to wholesale government surveillance.
>> 

Re: gcc extensibility

[Niels Möller]

Gabriel Dos Reis  writes:

> It is a false equality.  The needs of plugins authors are not necessarily
> the same as the need of GCC development itself.

I'm not so sure of that. To be concrete, can you give some examples of
things that a plugin might want to do with an interface to the
tree-abstraction in gcc, which gcc itself would never do? And vice
versa?

The typical needs may be different, but I don't think it's wise to a
priori rule out the possibility of designing, e.g, a tree API, which is
both powerful enough and clean enough to serve well both plugins and the
rest of gcc.

> You really do not want the existence of plugins to hinder (internal)
> evolution of GCC itself.

Agreed. Question is how much interface stability is needed by plugins,
and how often gcc internals must change important interfaces. I would
expect that binary compatibility is not terribly important, i.e., it's
acceptable if plugins sometimes have to be recompiled even for a new
minor release (and we don't want to allow proprietary binary-only
plugins anyway, right?).

Breaking source level compatibility ought to be avoided for minor
releases. But the current situation, where, due to the name mangling, it
seems difficult for a plugin to be compatible even with different
configurations of the *same* minor release of gcc, seems a bit too
inconvenient.

Then I'd also expect that certain interfaces, e.g., the tree interface,
can be a lot more stable than others.

Bottom line: When interface changes in gcc really are needed, then just
do them (preferably in connection with a major release), and plugins
will have to follow.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

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

[Richard Henderson]

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?

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: gcc extensibility

[Jonathan Wakely]

On 29 March 2012 17:52, Basile Starynkevitch wrote:
> On Thu, 29 Mar 2012 11:42:30 -0500
> Gabriel Dos Reis  wrote:
>> I suspect that if plugins people want to make progress on this
>> recurring theme, they
>> will have to come up with a specification and an API.  Otherwise, they have 
>> only
>> themselves to blame if their plugins break from release to release.
>
>
> They blame nobody if their plugins break from one release to the next. They 
> take this
> incompatibility of GCC as part of their plugins developer's work.
>
> Again, a plugin writer by definition uses whatever interface is given to him.

For a mature plugin API, maybe.

But plugins in GCC are still new and still evolving, if plugin authors
won't help shape the API and offer their advice now then they the API
will never be useful.

Don't expect people who don't care about plugins to do all the work of
making writing plugins easier.

Re: gcc extensibility

[Gabriel Dos Reis]

On Thu, Mar 29, 2012 at 12:39 PM, Romain Geissler
 wrote:
> Le 29 mars 2012 à 18:06, Gabriel Dos Reis a écrit :
>
>> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler
>>  wrote:
>>> Hi
>>>
>>> Le 29 mars 2012 à 14:34, Niels Möller a écrit :
>>>
 1. I imagine the plugin API ought to stay in plain C, right?
>>>
>>> I don't know if this was already discussed and if the community
>>> ended up with a clear answer for this question. If it's not the case
>>> i would prefer a plugin interface in C++, for the same reasons it
>>> was decided to slowly move the internals to C++.
>>>
>>
>> I do not think people working on plugins have come up with a
>> specification and an API they agree on.  Which makes any talk
>> of restricting GCC's own evolution premature if not pointless.
>
> I didn't mean the choice of C or C++ for the future plugin API may
> in any way alter the own GCC evolution. The API only consists in
> a bunch of stable wrappers to the unstable internals. Once such
> an API exists, that won't be hard to update the impacted wrappers
> to follow that changes, and thus it would have only minor impact on
> the internals evolution.
>

From past discussions,  I gather that the plugins people
want an uncompromising access to every bits of GCC internals (hence
resist any notion of specification and API) and don't want to see evolution
of GCC that might break their working plugins, for example using C++ because
 their own plugins are written in C.  Yet, we also receive lectures on modules
and what they should look like in GCC.  I have concluded that unless they sort
out their internal inconsistencies, there is no hope of seeing progress
any time son.

-- Gaby

Re: gcc extensibility

[Basile Starynkevitch]

On Thu, 29 Mar 2012 19:41:07 +0100
Jonathan Wakely  wrote:

> But plugins in GCC are still new and still evolving, if plugin authors
> won't help shape the API and offer their advice now then they the API
> will never be useful.
> 
> Don't expect people who don't care about plugins to do all the work of
> making writing plugins easier.

I actually agree with that. for the record, several PLUGIN events have been 
added at my
suggestion (notably those related to Ggc).

But I feel I don't wear the same hat as a plugin developer and as a GCC 
contributor.

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 mine, sont seulement les miennes} ***

Re: gcc extensibility

[Gabriel Dos Reis]

On Thu, Mar 29, 2012 at 1:31 PM, Niels Möller  wrote:
> Gabriel Dos Reis  writes:
>
>> It is a false equality.  The needs of plugins authors are not necessarily
>> the same as the need of GCC development itself.
>
> I'm not so sure of that. To be concrete, can you give some examples of
> things that a plugin might want to do with an interface to the
> tree-abstraction in gcc, which gcc itself would never do? And vice
> versa?

The question isn't what GCC developers -can- do and plugins can't do
or vice-versa.  The question is *why* GCC -ought- to be doing it the plugins
way.

[...]
> Breaking source level compatibility ought to be avoided for minor
> releases. But the current situation, where, due to the name mangling, it
> seems difficult for a plugin to be compatible even with different
> configurations of the *same* minor release of gcc, seems a bit too
> inconvenient.

I have read assertions from plugins people  that is part of their work as plugin
developers.  Consequently, on this end I don't think it is problem.  If
plugin people think it is a problem my suggestion is: sort it out!

-- Gaby

Re: gcc extensibility

[Pedro Alves]

On 03/29/2012 05:52 PM, Basile Starynkevitch wrote:

> On Thu, 29 Mar 2012 11:42:30 -0500
> Gabriel Dos Reis  wrote:
>> I suspect that if plugins people want to make progress on this
>> recurring theme, they
>> will have to come up with a specification and an API.  Otherwise, they have 
>> only
>> themselves to blame if their plugins break from release to release.
> 
> 
> They blame nobody if their plugins break from one release to the next. They 
> take this
> incompatibility of GCC as part of their plugins developer's work.
> 
> Again, a plugin writer by definition uses whatever interface is given to him.

IMO, the right way to approach this is instead:

#1 - I, a so called "plugin writer", have this use I could give to GCC,
 but it wouldn't make sense to include that code in the GCC sources/executable
 itself.  In fact, the maintainers would reject it, rightly.

#2 - However, if I could just add a little bit of glue interface to GCC
 that exposes just enough GCC internal bits that I could write my plugin
 against, in a way that is not invasive to the rest of the compiler,
 I know that would be accepted by the maintainers.  It's a compromise the
 GCC maintainers are willing to make.  They are aware that there's potential
 for other people to come up with other uses for the same minimal interfaces,
 so they accept this.  In the future, it's likely that other plugin authors
 will be satisfied by the interfaces I and other previous plugin authors have
 already added to GCC by then.

But, note it's clearly the plugin author that needs to write #2.  #1 too, 
obviously.  :-)

-- 
Pedro Alves

Re: gcc extensibility

[Diego Novillo]

On 3/29/12 3:01 PM, Basile Starynkevitch wrote:


But I feel I don't wear the same hat as a plugin developer and as a GCC 
contributor.


Yes, you do.  You are both a GCC contributor and a plugin developer.  As 
such, you are in a unique position to know the needs of both sides.


Cleaning up the internal interfaces in the compiler may help plugin 
developers.  Perhaps one thing you could help design and implement is a 
plugin-specific API that can evolve independently of the internal APIs 
in the compiler.


Plugins that need pervasive access to compiler internals will need to 
evolve with it, and expect to need changes at every release of the 
compiler.  Others will be protected by the plugin-specific interfaces.


If we ever convert the compiler into a collection of self-contained 
libraries, then some of the things that today require plugins will be 
able to use these libraries directly.



Diego.

Re: gcc extensibility

[Romain Geissler]

Le 29 mars 2012 à 21:01, Gabriel Dos Reis a écrit :

> On Thu, Mar 29, 2012 at 12:39 PM, Romain Geissler
>  wrote:
>> Le 29 mars 2012 à 18:06, Gabriel Dos Reis a écrit :
>> 
>>> On Thu, Mar 29, 2012 at 10:34 AM, Romain Geissler
>>>  wrote:
 Hi
 
 Le 29 mars 2012 à 14:34, Niels Möller a écrit :
 
> 1. I imagine the plugin API ought to stay in plain C, right?
 
 I don't know if this was already discussed and if the community
 ended up with a clear answer for this question. If it's not the case
 i would prefer a plugin interface in C++, for the same reasons it
 was decided to slowly move the internals to C++.
 
>>> 
>>> I do not think people working on plugins have come up with a
>>> specification and an API they agree on.  Which makes any talk
>>> of restricting GCC's own evolution premature if not pointless.
>> 
>> I didn't mean the choice of C or C++ for the future plugin API may
>> in any way alter the own GCC evolution. The API only consists in
>> a bunch of stable wrappers to the unstable internals. Once such
>> an API exists, that won't be hard to update the impacted wrappers
>> to follow that changes, and thus it would have only minor impact on
>> the internals evolution.
>> 
> 
> From past discussions,  I gather that the plugins people
> want an uncompromising access to every bits of GCC internals (hence
> resist any notion of specification and API) and don't want to see evolution
> of GCC that might break their working plugins, for example using C++ because
> their own plugins are written in C.  Yet, we also receive lectures on modules
> and what they should look like in GCC.  I have concluded that unless they sort
> out their internal inconsistencies, there is no hope of seeing progress
> any time son.

I completely agree (for my own, I don't ask for full featured API, and
prioritize any internal enhancement over plugin API enhancement)

pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Basile Starynkevitch]

Hello All,

The pre-release candidate 1 of MELT 0.9.5 is available for testing on
http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz
as a gzipped tar archive of 4473286 bytes and md5sum 
ae00b9bd31f481e1bbc406711ca4c2f4.
 extracted from MELT branch 185969, march 29th 2012

You could try building it e.g. with 
  make MELTGCC=gcc-4.7 GCCMELT_CC=gcc-4.7 
It seems to be also buildable for GCC 4.6 with
  make MELTGCC=gcc-4.6 GCCMELT_CC=gcc-4.6

(both commands sort of work, with perhaps minor issues very late in the build 
process;
I'm not very afraid of these)

But I'm trying to code a makefile which would autodetect in GCC 4.7 was 
compiled in C++
mode (or if the GCC was compiled in C mode, then it is probably a 4.6 or a 4.7
configured in a weird fashion).
 
So far I tried to code in my Makefile the following trick

## the compiler with which melt.so is used
ifndef MELTGCC
MELTGCC = $(or $(CC),gcc)
endif

## gives yes if MELTGCC has been built with C++ or else the empty string
MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define +ENABLE_BUILD_WITH_CXX +1' \
  `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)

## The compiler and flags used to build the melt.so plugin and to
## compile MELT generated code.  Notice that melt-module.mk use the
## same Make variables.  For a melt plugin to GCC 4.7 or later, that
## could be a C++ compiler! eg
##   make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7
## hence we add a test if $(MELTGCC) was built with C++ or with C
ifeq ($(strip $(MELTGCC_BUILD_WITH_CXX)),)
GCCMELT_CC ?= $(or $(CC),gcc) -Wc++-compat
else
GCCMELT_CC ?= $(or $(CXX),g++)
endif

GCCMELT_CFLAGS ?= -g -O -Wall

$(info MELT plugin for MELTGCC= $(MELTGCC) to be compiled with GCCMELT_CC= 
$(GCCMELT_CC) \
flags $(GCCMELT_CFLAGS) $(if $(MELTGCC_BUILD_WITH_CXX),built with C++ \
$(MELTGCC_BUILD_WITH_CXX)))
### rest of makefile skipped
#

but for some reason it does not work. (Maybe a := versus = make variable thing).

Do you have any suggestions about such things?  Assuming a plugin whose source 
code
should work with both 4.6 & 4.7, how would you autodetect if GCC was compiled 
in C++ or
in C mode? What am I doing wrong?

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 mine, sont seulement les miennes} ***

Re: gcc extensibility

[Basile Starynkevitch]

On Thu, 29 Mar 2012 15:22:28 -0400
Diego Novillo  wrote:

> On 3/29/12 3:01 PM, Basile Starynkevitch wrote:
> 
> > But I feel I don't wear the same hat as a plugin developer and as a GCC 
> > contributor.
> 
> Yes, you do.  You are both a GCC contributor and a plugin developer.  As 
> such, you are in a unique position to know the needs of both sides.

Well, I sort of agree, but I can't wear both hats *at the same time*. Either I 
feel as a
plugin developer, and then I struggle to make my plugin work with whatever 
versions of
GCC I have in mind, or I am a GCC contributor, and then I have to "forget" a 
bit my
plugin hat (of course keep "thinking" of my plugin needs). It is a bit like a 
kernel
developer who also develop a low level user-land application using his driver 
(imagine a
3D printer, or a computer-driven machining tool): when he develop the user-land 
thing
(imagine the 3D equivalent of CUPS, or a low-level CAD software for machining), 
he has to
aim some *existing* kernel version. Writing a plugin which would work only with 
an
experimental branch -and not with some GCC release, even a future one- is IMHO 
a complete
loss of time (and a huge but useless effort).

> Cleaning up the internal interfaces in the compiler may help plugin 
> developers.  Perhaps one thing you could help design and implement is a 
> plugin-specific API that can evolve independently of the internal APIs 
> in the compiler.

I am not sure to understand what you mean exactly. What is the plugin-specific 
API
(today, it is mostly the set of PLUGIN_* events, etc..). Or do you mean 
something else
which does not exist yet?

> 
> Plugins that need pervasive access to compiler internals will need to 
> evolve with it, and expect to need changes at every release of the 
> compiler. 
My feeling is that these "compiler internals" are actually the non-documented 
part of the
$(gcc -print-file-name=plugin/include) which today is the majority of the 
header files
there. Of course, I don't expect them to be stable. I do know they are not.
(And yes, sometimes these things bite and hurt).

> Others will be protected by the plugin-specific interfaces.
My feeling is that you think of the *documented* part of $(gcc
-print-file-name=plugin/include), that is the few things *documented* in 
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html

Or perhaps I (Basile) am misunderstanding you (Diego) entirely. Sorry for that 
if it is
the case!


> 
> If we ever convert the compiler into a collection of self-contained 
> libraries, then some of the things that today require plugins will be 
> able to use these libraries directly.

I feel it almost the opposite way. When GCC becomes modular, it will be made of 
a
defined (and easily countable, i.e. a dozen or two) collection of libraries 
(each have to
be named! Names of modules [or libraries if you like this word] are important 
both to the
linker and to the developers (in particular the newbies). And a good picture of 
GCC would
be important too (recall the Gnome/GTK picture I mentioned many times).
The point is that I Basile sadly do not have the broad view and culture about 
GCC than
you (Diego, and other global reviewers) have. So I cannot even propose a set of 
module
names (or library names, if that hurts you less). Only people like you (Diego, 
and other
global reviewers) could propose -for discussion- a set of module (that is 
library) names.
I don't know GCC enough to think of one, sorry about that (I really mean it: I 
have
almost no idea of what the backends are made of, or of what the C++ or Ada or Go
frontends are made of).

Once GCC is defined by a set of modules (or libraries, for me a top-level 
module Foo is
implemented as a libfoo.so; exactly as in the Gnome world the Pango module is 
implemented
as libpango.so; so top-level modules are exactly implemented as 
shared-libraries), plugins
would have a well defined interface to it. Even, a plugin might replace 
exactly, or
supplement, an entire library (that would enable, for instance, providing a 
front-end or
a back-end as a plugin).

My feeling about a GCC modularity is that it would help *tremendously* if we 
have some
mechanical mean to describe -in details- that set of module. My feeling is that 
GTK could
teach us a lot about that (this does not mean that we should adopt GTK 
technology, just
that we should be inspired by GTK "philosophy" - but calling that a philosophy 
is an
insult towards the great philosophers like Socrate, Kant, etc...).

My dream -in particular because it would help MELT, and any language binding 
[Python,
Ruby, Ocaml, ...] to GCC- would be that GCC would have some meta-API, à la
http://live.gnome.org/GObjectIntrospection to query the set of modules and the 
large set
of API inside).

My other dream would be to have some plugins to help us (but sadly, I am not 
funded to
work on that; I would be delighted to be funded to use MELT for developping 
such MELT
extensions to help GCC) on that goal. It is quit

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

[Eric Botcazou]

> non-call-exceptions is a relatively big hammer.  It marks _all_
> non-trivial instructions as throwing.

The "all" goes against the "relatively" here, and "relatively" is more correct.
Not all non-trivial instructions are marked as throwing, e.g. loads and stores 
from/to the stack aren't.

-- 
Eric Botcazou

Re: [GCC-MELT-386] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Romain Geissler]

Le 29 mars 2012 à 22:02, Basile Starynkevitch a écrit :

> 
> Hello All,
> 
> The pre-release candidate 1 of MELT 0.9.5 is available for testing on
> http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz
> as a gzipped tar archive of 4473286 bytes and md5sum 
> ae00b9bd31f481e1bbc406711ca4c2f4.
> extracted from MELT branch 185969, march 29th 2012
> 
> You could try building it e.g. with 
>  make MELTGCC=gcc-4.7 GCCMELT_CC=gcc-4.7 
> It seems to be also buildable for GCC 4.6 with
>  make MELTGCC=gcc-4.6 GCCMELT_CC=gcc-4.6
> 
> (both commands sort of work, with perhaps minor issues very late in the build 
> process;
> I'm not very afraid of these)
> 
> But I'm trying to code a makefile which would autodetect in GCC 4.7 was 
> compiled in C++
> mode (or if the GCC was compiled in C mode, then it is probably a 4.6 or a 4.7
> configured in a weird fashion).
> 
> So far I tried to code in my Makefile the following trick
> 
> ## the compiler with which melt.so is used
> ifndef MELTGCC
> MELTGCC = $(or $(CC),gcc)
> endif
> 
> ## gives yes if MELTGCC has been built with C++ or else the empty string
> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define +ENABLE_BUILD_WITH_CXX +1' \
>  `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
> 
> ## The compiler and flags used to build the melt.so plugin and to
> ## compile MELT generated code.  Notice that melt-module.mk use the
> ## same Make variables.  For a melt plugin to GCC 4.7 or later, that
> ## could be a C++ compiler! eg
> ##   make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7
> ## hence we add a test if $(MELTGCC) was built with C++ or with C
> ifeq ($(strip $(MELTGCC_BUILD_WITH_CXX)),)
> GCCMELT_CC ?= $(or $(CC),gcc) -Wc++-compat
> else
> GCCMELT_CC ?= $(or $(CXX),g++)
> endif
> 
> GCCMELT_CFLAGS ?= -g -O -Wall
> 
> $(info MELT plugin for MELTGCC= $(MELTGCC) to be compiled with GCCMELT_CC= 
> $(GCCMELT_CC) \
> flags $(GCCMELT_CFLAGS) $(if $(MELTGCC_BUILD_WITH_CXX),built with C++ \
> $(MELTGCC_BUILD_WITH_CXX)))
> ### rest of makefile skipped
> #
> 
> but for some reason it does not work. (Maybe a := versus = make variable 
> thing).
> 
> Do you have any suggestions about such things?  Assuming a plugin whose 
> source code
> should work with both 4.6 & 4.7, how would you autodetect if GCC was compiled 
> in C++ or
> in C mode? What am I doing wrong?
> 
> 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 mine, sont seulement les miennes} ***
> 
> -- 
> Message from the http://groups.google.com/group/gcc-melt group.
> About GCC MELT http://gcc-melt.org/ a high level domain specific language to 
> code extensions to the Gnu Compiler Collection

Hi, 

You almost got it. You simply need to backslash escape the '+' operator in your 
regexp.
Also, it would be welcome to allow any blank chars to separate words, not any 
the space char
(\t for example). Thus, i changed space ' ' by [[:space:]] (tested with GNU 
grep).

MELTGCC_BUILD_WITH_CXX = $(shell grep -q 
'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
  `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)

Anyway, as i already told you, you don't look for gengtype and gtype.state at 
the right place.

Romain Geissler

Proposed plugin API for GCC

[David Malcolm]

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?
How do GCC subsystem maintainers feel?

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
Dave

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Basile Starynkevitch]

On Thu, 29 Mar 2012 22:45:27 +0200
Romain Geissler  wrote:

> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 
> 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
>   `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
> 

Thanks; I applied that patch with


2012-03-29  Romain Geissler  
* MELT-Plugin-Makefile (MELTGCC_BUILD_WITH_CXX): Better grep.


(I will test it tomorrow)
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 mine, sont seulement les miennes} ***

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Romain Geissler]

Le 29 mars 2012 à 23:03, Basile Starynkevitch a écrit :

> On Thu, 29 Mar 2012 22:45:27 +0200
> Romain Geissler  wrote:
> 
>> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 
>> 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \
>>  `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes)
>> 
> 
> Thanks; I applied that patch with
> 
> 
> 2012-03-29  Romain Geissler  
>   * MELT-Plugin-Makefile (MELTGCC_BUILD_WITH_CXX): Better grep.
> 
> 
> (I will test it tomorrow)
> Cheers.

You've made a typo will copy/pasting part of the line. Look at the dollar $ char
near '=$ (shell)', the space is misplaced. It should be '= $(shell'.

Romain Geissler

Re: GSoC proposal: Provide optimizations feedback through post-compilation messages

[Tomasz Borowik]

On Tue, 27 Mar 2012 22:33:39 +
Thibault Raffaillac  wrote:

> Hello all,
> 
> My name is Thibault Raffaillac, CS degree student at Kungliga Tekniska 
> Högskolan,
> Stockholm, Sweden (in double-degree partnership with Ecole Centrale Marseille,
> France).
> GCC currently provides no concise way to inform the user whether it applied an
> expected optimization (ie, it "understood" the code). As a result, some will 
> do
> premature optimizations when they do not trust the compiler, and some others
> will create overly convoluted code with blind belief in the compiler. This is
> especially relevant for users non-initiated to the internals of GCC.
> The project I would like to propose is a feedback for the optimizations
> performed by GCC. To avoid binding users to the compiler, I would focus on 
> some
> very standard optimizations across vendors, or for some specific yet nice
> features I would indicate their specificity to GCC/an architecture.
> 
> The feedback would be triggered when compilation is successful, and display a
> couple of different messages each time it is run:
> gcc --feedback test.c
> test.c:xx:x: info: All operands being constant, constant folding was applied 
> to assign '2560' to 'a'
> test.c:xx:x: info: GCC could not fold constants here because...
> test.c:xx:x: info: As integers are stored in binary format, strength 
> reduction was applied to replace '* 8' by '<< 3'
> test.c:xx:x: info: Basic block vectorization was applied to pack the 3 
> independent additions into a single SIMD instruction
> test.c:xx:x: info: GCC implements unordered_map as open-addressed hash 
> tables, with double hashing probing
> 
> As a difference with the internal verbose messages, here they would form a 
> set,
> and the system would remember those already displayed and decrease their
> frequency of occurence between compilations. All messages would explain what
> triggered them, cite the optimization name, and describe the consequence.
> 
> As for the work plan, it would consist in:
> _ Enumerating all possible messages in the messages set.
> _ Implementing a function receiving feedback from each optimization unit and
>   choosing whether to display it: info_printf(enum INFO_INDEX, const char*, 
> ...);
> _ Write a formatting guide for adding messages in the set.
> 
> My academic background includes compiler construction, C programming and 
> Human-
> Computer Interactions. I am very much interested in the usability of compilers
> (on which I am currently carrying my degree thesis -
> http://www.csc.kth.se/~traf/traf-sketch.pdf) and thus would be glad to
> contribute to GCC.
> 
> If this can be of interest, suggestions are welcome!
> 
> Best regards,
> Thibault (http://www.csc.kth.se/~traf/)
> 

Hi Thibault,

I completely agree, and it's actually a part of what I'm targeting in the long 
term, so I think we might be able to join forces. I'm also thinking of a gsoc 
project though in different areas (there's an email in the list about them on 
19.03), so maybe we could do separate parts that combine into something even 
more awesome;)

I think a huge part of the issue is in the medium of communication between the 
programmer and compiler. I'm targeting an environment where the source code 
editor practically becomes the compiler's front-end. My project allows 
extremely dynamic presentation of the source code, so I can e.g.
 - easily inform the programmer about anything in an unobtrusive manner within 
the code, 
 - give him different perspectives of the same code,
 - allow him to give precise and detailed information to the compiler about 
possible code optimizations without making the code unreadable.

The first two points may seem already solved by eclipse, xcode or whatever 
other gigantic ide, but I'm talking about a much larger scale of feedback 
presented instantly like: ex/implicit and inferred typing info, constant folds, 
dead code, unfolded loops, data flow, vector operations, tree view of 
expressions.

The first issue is that for any non trivial amount of code you'll end up with 
thousands of messages 90% of which are probably not very interesting (similarly 
to warnings in a certain style of objective programming in C). As long as the 
output is not interleaved with the code at the right place and the delay from 
writing to getting feedback is too long, the feature will loose much of its 
usefullness. Though don't misunderstand me, I think it's still better to have 
the info in any form than not.

The last point is probably the more important, as there often is a large amount 
of optimizations that cannot be done due to for example pointer aliasing rules, 
but the programmer knows that the optimization is safe. I can easily add 
literally hundreds of markers like "this expression is volatile", "the result 
of this function call will not change within this loop", "these two pointers 
don't alias" and it wouldn't obfuscate the code as much as with normal 
languages. Furthermore my editor can 

Re: Proposed plugin API for GCC

[Miles Bader]

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.

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: unwind and type support in GCC47

[Ian Lance Taylor]

"Paulo J. Matos"  writes:

> I am porting my backend to GCC47 and have been jumping through some 
> hurdles. libgcc is trying to compile unwind*.c files which I can't 
> remember being there for GCC46.

They were there.  In 4.6 they were in the gcc subdirectory.  For 4.7
they moved to the libgcc directory.  This was a logical move because
they have always been part of libgcc, not part of the compiler (and
enormous thanks for Rainer Orth for working through the mechanics of
moving them.)


> I deduce this files have to do with 
> exception support GCC47 seems to want to make exceptions mandatory even 
> though my backend doesn't really 'support' them (in the sense that our 
> tests don't care about them).

The files didn't change when they moved.  It is possible that something
about how they were built changed.


> unwind*.c have a lot of variable definitions to mode SI as being a word, 
> However, in my case a word is actually in mode QI (16bits). Is there 
> anything I can do to stop libgcc from trying to compile these files

Sure, change LIB2ADDEH in your libgcc/config/CPU/t-CPU file.  E.g., see
picochip.

> or to 
> make unwind compatible with my backend besides going blindly changing SI 
> mode in variable declaration to QI mode?

There really shouldn't be anything in the exception support that uses
SImode.  That would be a bug.  And I don't see anything that uses
SImode.  What are you looking at?  What I see is things that use mode
__unwind_word__, __word__, and __pointer__.  Those types are under the
control of your backend.

Ian

Re: Backends with no exception handling on GCC47

[Ian Lance Taylor]

"Paulo J. Matos"  writes:

> Is there anything documenting porting backend between GCC major versions 
> (GCC4.6 - GCC4.7), in order to avoid these questions?

Basically, everything related to library code should move from
gcc/config/CPU to libgcc/config/CPU.  I don't know of any specific
documentation about this change.

Ian

Re: Proposed plugin API for GCC

[Ian Lance Taylor]

David Malcolm  writes:

> 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

Seems like a good start.

> 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.

Predictably, I don't care for the names.

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

Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues)

[Basile Starynkevitch]

On Thu, 29 Mar 2012 23:29:40 +0200
Romain Geissler  wrote:
> 
> You've made a typo will copy/pasting part of the line. Look at the dollar $ 
> char
> near '=$ (shell)', the space is misplaced. It should be '= $(shell'.


Thanks! Corrected.


-- 
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 mine, sont seulement les miennes} ***