Re: GCC Plug-in Framework ready to port

[Richard Guenther]

On Sat, Jan 31, 2009 at 5:01 AM, Sean Callanan  wrote:
> Dear mailing list:
>
> My research group (the High-Confidence Operating Systems group at Stony
> Brook University;
> home page http://www.fsl.cs.sunysb.edu/hcos/) continues to use a modified
> branch of
> Subversion GCC that hosts plug-ins written in C, C++, and (with a little
> work) Python.
>
> We published a GCC Summit paper on this, called "Extending GCC with Modular
> GIMPLE
> Optimizations" (Callanan, Dean, and Zadok).  We have developed a variety of
> plug-ins,
> including:
>
> - A GIMPLE virtual machine, developed by another team at the university,
> - A generic run-time AOP architecture, currently in preparation,
> - Bounds-checkers and execution tracers,
>
> and more.
>
> We are willing to contribute the effort necessary to integrate this system
> into the current
> main-line GCC, and feel that it is simple and general enough that many other
> systems could
> be built on top of it.
>
> We've been off the ML for some time, but we're still out there.  Is this
> something that is
> wanted, or have we been overtaken by events and should be porting to someone
> else's
> implementation?

I would suggest that people that want their plugin machine included in GCC
should start sending patches integrating the core infrastructure.  The
most useful
feedback you will get from the review process, and the more groups start doing
this the earlier we will see the needs of the different groups.

Especially if you are targeting GCC 4.5 you should be aware that you probably
have about half a year from now to finish integration.

Thanks,
Richard.

> Sincerely,
> Sean Callanan
>

Re: Creating imaginary inf/nan in GCC

[Richard Guenther]

On Sat, Jan 31, 2009 at 5:26 AM, Kaveh R. Ghazi  wrote:
> From: "Tobias Burnus" 
>
>> Hi Kaveh,
>>
>> Kaveh R. GHAZI wrote:
>>>
>>> I'm trying to create complex number expressions that contain inf or
>>> nan in the imaginary part.  I.e. (0 + inf I) or (0 + nan I).
>>
>> If it does not need to be C (e.g. to try MPC in the middle end), you
>> could use Fortran:
>>
>> ! compile with gfortran -fno-range-check
>> complex :: z
>> z = cmplx(0.0, 0.0/0.0)
>> print *, z
>> end
>>
>> Tobias
>
> Thanks, I do want to test the middle-end.  However I need to do more than
> just create the complex expression.  I also have to pass it to a builtin
> that evaluates using MPC like __builtin_csin().  The fortran frontend
> evaluates complex transcendentals in fortran/simplify.c, not in the
> middle-end.  So it wouldn't test what I want AFAICT.  It's not a big deal,
> the nan cases are error paths that should *avoid* folding via MPC.

If you go through memory the compiler should promote that to a register
and constant propagate the result, isn't that enough?

Thanks,
Richard.

>   Regards,
>   --Kaveh
>
>

GCC 4.4.0 Status Report (2009-01-31)

[Jakub Jelinek]

Status
==

The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.

The number of P1, P2 and P3 regressions is already under 100 and the only
remaining P1 has a patch approved.  The old register allocator has been
removed.  The 4.4 branch will be created when all the P1 fixes are committed
and the licensing changes (see the GCC Runtime Library Exception thread on
gcc mailing list) land on the trunk.

Quality Data


Priority  # Change from Last Report
--- ---
P11 - 11
P2   91 - 21
P30 -  4
--- ---
Total92 - 36

Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-01/msg00051.html

The next report for 4.4.0 will be sent by Joseph.

Re: MIPS64 -msym32 and DWARF2_ADDR_SIZE

[Richard Sandiford]

Adam Nemet  writes:
> -msym32 changes DWARF's address_size from 64 bits to 32 bits.  This means that
> while symbols are 64-bit (due to ELF64), target addresses in the debug info
> are 32-bit.
>
> There is support for this in DWARF of course in fact you can specify different
> address_size for each compilation unit which nicely maps with -msym32 being
> link-compatible with regular N64 objects.
>
> However, this asymmetry exposed several bugs in binutils.  Also, as I just
> discovered today, dwarfdump (libdwarf) has no support for changing the
> address_size between compilation units and in fact derives address_size from
> the ELF class (ELF64/ELF32).  (Obviously, that's a bug in libdwarf.)

Good catch.

> So my question is whether the saving in the size of the debug info with
> -msym32 is really worth the trouble here or should we just start generating
> 64-bit addresses with -msym32?

Generating 64-bit addresses would be fine with me FWIW.  I'm not sure
the current behaviour is exactly deliberate; it was probably just
something I overlooked when adding -msym32.

How about the patch below?  I'll apply it in the next couple of days
if there are no objections.

Richard


gcc/
* config/mips/mips.h (FILE_HAS_64BIT_SYMBOLS): New macro.
(ABI_HAS_64BIT_SYMBOLS): Use it.
(DWARF2_ADDR_SIZE): Use it instead of ABI_HAS_64BIT_SYMBOLS.

Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h  2009-01-31 12:21:01.0 +
+++ gcc/config/mips/mips.h  2009-01-31 12:38:03.0 +
@@ -767,9 +767,15 @@ #define ABI_NEEDS_64BIT_REGS   (TARGET_NEW
 /* Likewise for 32-bit regs.  */
 #define ABI_NEEDS_32BIT_REGS   (mips_abi == ABI_32)
 
-/* True if symbols are 64 bits wide.  At present, n64 is the only
-   ABI for which this is true.  */
-#define ABI_HAS_64BIT_SYMBOLS  (mips_abi == ABI_64 && !TARGET_SYM32)
+/* True if the file format uses 64-bit symbols.  At present, this is
+   only true for n64, which uses 64-bit ELF.  */
+#define FILE_HAS_64BIT_SYMBOLS (mips_abi == ABI_64)
+
+/* True if symbols are 64 bits wide.  This is usually determined by
+   the ABI's file format, but it can be overridden by -msym32.  Note that
+   overriding the size with -msym32 changes the ABI of relocatable objects,
+   although it doesn't change the ABI of a fully-linked object.  */
+#define ABI_HAS_64BIT_SYMBOLS  (FILE_HAS_64BIT_SYMBOLS && !TARGET_SYM32)
 
 /* ISA has instructions for managing 64-bit fp and gp regs (e.g. mips3).  */
 #define ISA_HAS_64BIT_REGS (ISA_MIPS3  \
@@ -1218,7 +1224,14 @@ #define DWARF2_DEBUGGING_INFO 1 
 #define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
 #endif
 
-#define DWARF2_ADDR_SIZE (ABI_HAS_64BIT_SYMBOLS ? 8 : 4)
+/* The size of DWARF addresses should be the same as the size of symbols
+   in the target file format.  They shouldn't depend on things like -msym32,
+   because many DWARF consumers do not allow the mixture of address sizes
+   that one would then get from linking -msym32 code with -msym64 code.
+
+   Note that the default POINTER_SIZE test is not appropriate for MIPS.
+   EABI64 has 64-bit pointers but uses 32-bit ELF.  */
+#define DWARF2_ADDR_SIZE (FILE_HAS_64BIT_SYMBOLS ? 8 : 4)
 
 /* By default, turn on GDB extensions.  */
 #define DEFAULT_GDB_EXTENSIONS 1

Re: GCC Plug-in Framework ready to port

[Diego Novillo]

On Fri, Jan 30, 2009 at 23:01, Sean Callanan  wrote:

> We've been off the ML for some time, but we're still out there.
> Is this something that is wanted, or have we been overtaken
> by events and should be porting to someone else's
> implementation?

Thanks for raising the issue.  The last time we discussed this
issue (http://gcc.gnu.org/ml/gcc/2008-09/msg00292.html), we did
not reach a final decision, but now that the licensing issues
have been clarified I think it's time we created a branch for
future merging.

I understand that there are several branches or patchsets for the
various approaches.  We clearly need to converge into a single
one.  My proposal is:

1- Agree on a common API and document it in
   http://gcc.gnu.org/wiki/GCC_PluginAPI

2- Create a new branch to implement that common API.  The branch
   would *only* be for basic plugin functionality.

3- Decide whether there are plugins that we would want to have in
   the standard distribution.  I suspect that we will just want 1
   or 2 basic applications as examples.  Or perhaps, plugins
   that are so universally useful for GCC development or users
   that we decide to include them.

I offer to create and maintain the new branch, help with patch
reviews and merge it into trunk at the next stage 1.

As Richard said, there is still time (several months), and I
don't think the patches needed to implement the basic plugin
harness are going to be all that large.  However, it is important
that we agree on an API so that every group can easily port their
plugins to it.


Diego.

Re: GCC Plug-in Framework ready to port

[Richard Guenther]

On Sat, Jan 31, 2009 at 2:11 PM, Diego Novillo  wrote:
> On Fri, Jan 30, 2009 at 23:01, Sean Callanan  wrote:
>
>> We've been off the ML for some time, but we're still out there.
>> Is this something that is wanted, or have we been overtaken
>> by events and should be porting to someone else's
>> implementation?
>
> Thanks for raising the issue.  The last time we discussed this
> issue (http://gcc.gnu.org/ml/gcc/2008-09/msg00292.html), we did
> not reach a final decision, but now that the licensing issues
> have been clarified I think it's time we created a branch for
> future merging.
>
> I understand that there are several branches or patchsets for the
> various approaches.  We clearly need to converge into a single
> one.  My proposal is:
>
> 1- Agree on a common API and document it in
>   http://gcc.gnu.org/wiki/GCC_PluginAPI

Note that even for this taks being able to compare what the existing frameworks
implement (with code) would help a lot.  After all, source code tells more
than 1000 "design" words ;)

Richard.

Re: GCC Plug-in Framework ready to port

[Diego Novillo]

On Sat, Jan 31, 2009 at 08:24, Richard Guenther
 wrote:
> On Sat, Jan 31, 2009 at 2:11 PM, Diego Novillo  wrote:
>>
>> 1- Agree on a common API and document it in
>>   http://gcc.gnu.org/wiki/GCC_PluginAPI
>
> Note that even for this taks being able to compare what the existing 
> frameworks
> implement (with code) would help a lot.  After all, source code tells more
> than 1000 "design" words ;)

Sure, but we will be retrofitting existing implementations into a
unified API, and the various groups have gathered quite a bit of
experience already, so I expect the API to be fairly pragmatic.

I also don't think this will be a very complicated API.


Diego.

RE: GCC Plug-in Framework ready to port

[Grigori Fursin]

Hi all,
Just to mention that we nearly finished the developments of the new GCC ICI
on top of the latest branch (Zbigniew Chamski is working on that) and 
are finishing the documentation on Wiki. It was enhanced based on the feedback
of the current users while still keeping the core code of the plug-ins framework
simple. We should make it public in a week or two, will provide several 
examples 
from industry and would be very happy to discuss further directions ...
Will keep in touch,
Grigori


> -Original Message-
> From: Diego Novillo [mailto:dnovi...@google.com]
> Sent: Saturday, January 31, 2009 2:28 PM
> To: Richard Guenther
> Cc: Sean Callanan; Taras Glek; Basile STARYNKEVITCH; Grigori Fursin; Le-Chun 
> Wu; Brendon
> Costa; Emmanuel Fleury; gcc@gcc.gnu.org
> Subject: Re: GCC Plug-in Framework ready to port
> 
> On Sat, Jan 31, 2009 at 08:24, Richard Guenther
>  wrote:
> > On Sat, Jan 31, 2009 at 2:11 PM, Diego Novillo  wrote:
> >>
> >> 1- Agree on a common API and document it in
> >>   http://gcc.gnu.org/wiki/GCC_PluginAPI
> >
> > Note that even for this taks being able to compare what the existing 
> > frameworks
> > implement (with code) would help a lot.  After all, source code tells more
> > than 1000 "design" words ;)
> 
> Sure, but we will be retrofitting existing implementations into a
> unified API, and the various groups have gathered quite a bit of
> experience already, so I expect the API to be fairly pragmatic.
> 
> I also don't think this will be a very complicated API.
> 
> 
> Diego.

Re: GCC 4.4.0 Status Report (2009-01-31)

[H.J. Lu]

On Sat, Jan 31, 2009 at 4:34 AM, Jakub Jelinek  wrote:
> Status
> ==
>
> The trunk remains Stage 4, so only fixes for regressions (and changes
> to documentation) are allowed.
>
> The number of P1, P2 and P3 regressions is already under 100 and the only
> remaining P1 has a patch approved.  The old register allocator has been
> removed.  The 4.4 branch will be created when all the P1 fixes are committed
> and the licensing changes (see the GCC Runtime Library Exception thread on
> gcc mailing list) land on the trunk.
>
> Quality Data
> 
>
> Priority  # Change from Last Report
> --- ---
> P11 - 11

I checked in the fix for PR38952.  There should no P1 regression now.

> P2   91 - 21
> P30 -  4
> --- ---
> Total92 - 36
>
> Previous Report
> ===
>
> http://gcc.gnu.org/ml/gcc/2009-01/msg00051.html
>
> The next report for 4.4.0 will be sent by Joseph.
>



-- 
H.J.

Re: GCC 4.4.0 Status Report (2009-01-31)

[Dave Korn]

H.J. Lu wrote:
> On Sat, Jan 31, 2009 at 4:34 AM, Jakub Jelinek  wrote:
>> Status
>> ==
>>
>> The trunk remains Stage 4, so only fixes for regressions (and changes
>> to documentation) are allowed.
>>
>> The number of P1, P2 and P3 regressions is already under 100 and the only
>> remaining P1 has a patch approved.  The old register allocator has been
>> removed.  The 4.4 branch will be created when all the P1 fixes are committed
>> and the licensing changes (see the GCC Runtime Library Exception thread on
>> gcc mailing list) land on the trunk.
>>
>> Quality Data
>> 
>>
>> Priority  # Change from Last Report
>> --- ---
>> P11 - 11
>
> I checked in the fix for PR38952.  There should no P1 regression now.

  Thanks HJ, I think it's had enough testing even if the cygwin runs haven't
all completely finished.

  Joseph/Jakub, I have all the required OKs to check in the patch for PR38904:

http://gcc.gnu.org/ml/gcc-patches/2009-01/threads.html#01133

may I quickly check that in before you branch?

cheers,
  DaveK

Re: GCC 4.4.0 Status Report (2009-01-31)

[John David Anglin]

> removed.  The 4.4 branch will be created when all the P1 fixes are committed
> and the licensing changes (see the GCC Runtime Library Exception thread on
> gcc mailing list) land on the trunk.

I noticed sometime ago that two files in the PA backend were incorrectly
changed from GPL 2 to GPL 3.  The files are fptr.c and milli64.S.  These
files are part of libgcc.  Could this be corrected when the GCC Runtime
Library Exception is done?

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: GCC 4.4.0 Status Report (2009-01-31)

[Richard Guenther]

On Sat, Jan 31, 2009 at 6:57 PM, John David Anglin
 wrote:
>> removed.  The 4.4 branch will be created when all the P1 fixes are committed
>> and the licensing changes (see the GCC Runtime Library Exception thread on
>> gcc mailing list) land on the trunk.
>
> I noticed sometime ago that two files in the PA backend were incorrectly
> changed from GPL 2 to GPL 3.  The files are fptr.c and milli64.S.  These
> files are part of libgcc.  Could this be corrected when the GCC Runtime
> Library Exception is done?

I guess it is safer if you do that yourself, as this presumably also
applied to the
branches?

Richard.

> Dave
> --
> J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
> National Research Council of Canada  (613) 990-0752 (FAX: 
> 952-6602)
>

Re: GCC 4.4.0 Status Report (2009-01-31)

[Richard Guenther]

On Sat, Jan 31, 2009 at 6:48 PM, Dave Korn
 wrote:
> H.J. Lu wrote:
>> On Sat, Jan 31, 2009 at 4:34 AM, Jakub Jelinek  wrote:
>>> Status
>>> ==
>>>
>>> The trunk remains Stage 4, so only fixes for regressions (and changes
>>> to documentation) are allowed.
>>>
>>> The number of P1, P2 and P3 regressions is already under 100 and the only
>>> remaining P1 has a patch approved.  The old register allocator has been
>>> removed.  The 4.4 branch will be created when all the P1 fixes are committed
>>> and the licensing changes (see the GCC Runtime Library Exception thread on
>>> gcc mailing list) land on the trunk.
>>>
>>> Quality Data
>>> 
>>>
>>> Priority  # Change from Last Report
>>> --- ---
>>> P11 - 11
>>
>> I checked in the fix for PR38952.  There should no P1 regression now.
>
>  Thanks HJ, I think it's had enough testing even if the cygwin runs haven't
> all completely finished.
>
>  Joseph/Jakub, I have all the required OKs to check in the patch for PR38904:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-01/threads.html#01133
>
> may I quickly check that in before you branch?

Sure.

Richard.

>cheers,
>  DaveK
>

Re: GCC 4.4.0 Status Report (2009-01-31)

[Dave Korn]

Richard Guenther wrote:
>>  Joseph/Jakub, I have all the required OKs to check in the patch for PR38904:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2009-01/threads.html#01133
>>
>> may I quickly check that in before you branch?
>
> Sure.

  Thanks, just updating my sandbox right now.

cheers,
  DaveK

Re: Creating imaginary inf/nan in GCC

[Kaveh R. Ghazi]

From: "Joseph S. Myers" 


On Thu, 29 Jan 2009, Kaveh R. GHAZI wrote:

I don't think these results are a bug, rather it's just an artifact of 
the

way complex multiplcation is done and having these special values in


See bug 24581.  Some aspects are a bug (GCC doesn't handle mixed
real/complex arithmetic the way it should), some are the lack of imaginary
types (though the only use of imaginary types I know of is this one for
building up constants, and no-one on the Power ABI working group could
find any implementation for Power Architecture that actually supports
imaginary types).


Thanks for the PR pointer.  I'm going to ask the obvious question, if 
there's an obvious answer please excuse me.  :-)


Would it be sufficient and correct to treat (0.0 + I) * y as a special case 
for MULT_EXPR and just swap the real and imaginary parts of "y" in the 
result?


   --Kaveh

Re: GCC 4.4.0 Status Report (2009-01-31)

[Dave Korn]

Dave Korn wrote:
> Richard Guenther wrote:
>>>  Joseph/Jakub, I have all the required OKs to check in the patch for 
>>> PR38904:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2009-01/threads.html#01133
>>>
>>> may I quickly check that in before you branch?
>> Sure.
>
>   Thanks, just updating my sandbox right now.

  All done now.  Thanks for your patience.

cheers,
  DaveK

Re: GCC 4.4.0 Status Report (2009-01-31)

[John David Anglin]

> > I noticed sometime ago that two files in the PA backend were incorrectly
> > changed from GPL 2 to GPL 3.  The files are fptr.c and milli64.S.  These
> > files are part of libgcc.  Could this be corrected when the GCC Runtime
> > Library Exception is done?
> 
> I guess it is safer if you do that yourself, as this presumably also
> applied to the
> branches?

Applied the following to trunk, 4.3 and 4.2 branches.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

2009-01-31  John David Anglin  

* config/pa/fptr.c: Revert license to GPL 2.
* config/pa/milli64.S: Likewise.

Index: config/pa/fptr.c
===
--- config/pa/fptr.c(revision 143821)
+++ config/pa/fptr.c(working copy)
@@ -6,7 +6,7 @@
 
 GCC is free software; you can redistribute it and/or modify it under
 the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 3, or (at your option) any later
+Software Foundation; either version 2, or (at your option) any later
 version.
 
 In addition to the permissions in the GNU General Public License, the
@@ -24,8 +24,9 @@
 for more details.
 
 You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
+along with GCC; see the file COPYING.  If not, write to the Free
+Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301, USA.  */
 
 /* WARNING: The code is this function depends on internal and undocumented
details of the GNU linker and dynamic loader as implemented for parisc
Index: config/pa/milli64.S
===
--- config/pa/milli64.S (revision 143821)
+++ config/pa/milli64.S (working copy)
@@ -8,7 +8,7 @@
 
 GCC is free software; you can redistribute it and/or modify it under
 the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 3, or (at your option) any later
+Software Foundation; either version 2, or (at your option) any later
 version.
 
 In addition to the permissions in the GNU General Public License, the
@@ -26,8 +26,9 @@
 for more details.
 
 You should have received a copy of the GNU General Public License
-   along with GCC; see the file COPYING3.  If not see
-.  */
+along with GCC; see the file COPYING.  If not, write to the Free
+Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301, USA.  */
 
 #ifdef pa64
 .level  2.0w

Re: GCC Plug-in Framework ready to port

[Taras Glek]

Diego Novillo wrote:

On Fri, Jan 30, 2009 at 23:01, Sean Callanan  wrote:

  

We've been off the ML for some time, but we're still out there.
Is this something that is wanted, or have we been overtaken
by events and should be porting to someone else's
implementation?



Thanks for raising the issue.  The last time we discussed this
issue (http://gcc.gnu.org/ml/gcc/2008-09/msg00292.html), we did
not reach a final decision, but now that the licensing issues
have been clarified I think it's time we created a branch for
future merging.

I understand that there are several branches or patchsets for the
various approaches.  We clearly need to converge into a single
one.  My proposal is:

1- Agree on a common API and document it in
   http://gcc.gnu.org/wiki/GCC_PluginAPI
  
Why not start the branch with the API as is described and then change it 
as people find problems with it. I am guessing we should converge on an 
API that the majority of users are happy with fairly quickly.

2- Create a new branch to implement that common API.  The branch
   would *only* be for basic plugin functionality.
  
Where would plugin-centric enhancements such as improvements to the pass 
manager go? i think it'd be useful to have them land in the plugin 
branch to make sure the API is satisfactory.

3- Decide whether there are plugins that we would want to have in
   the standard distribution.  I suspect that we will just want 1
   or 2 basic applications as examples.  Or perhaps, plugins
   that are so universally useful for GCC development or users
   that we decide to include them.
  
One simple and useful plugin could be a per-function warning suppressor. 
ie functions flagged with user(no-warn-unused-variable) could suppress a 
particular false warning.

I offer to create and maintain the new branch, help with patch
reviews and merge it into trunk at the next stage 1.

As Richard said, there is still time (several months), and I
don't think the patches needed to implement the basic plugin
harness are going to be all that large.  However, it is important
that we agree on an API so that every group can easily port their
plugins to it.
  
Indeed. As a maintainer of a couple gcc plugins and a corresponding API, 
what can I do to help out?



Taras

https://developer.mozilla.org/En/Dehydra

Re: GCC Plug-in Framework ready to port

[Joseph S. Myers]

On Sat, 31 Jan 2009, Diego Novillo wrote:

> 1- Agree on a common API and document it in
>http://gcc.gnu.org/wiki/GCC_PluginAPI
> 
> 2- Create a new branch to implement that common API.  The branch
>would *only* be for basic plugin functionality.

I also think it is strongly desirable that the configure macros (and maybe 
other build support) for use of plugin writers should be included for the 
support to be considered reasy to merge to trunk.  See my comments at 
 about what they might 
do, and about installation directories for files associated with plugins.

With properly designed configure macros and build support, plugin writers 
should not need to change their plugins to support new hosts (if, for 
example, the initial implementation is limited to ELF hosts and plugins 
need to build significantly differently for Windows hosts) - just to 
regenerate their configure scripts etc. with a newer copy of the macros.

Obviously everyone working on plugin infrastructure who isn't already an 
FSF GCC contributor should make sure all their copyright assignment 
paperwork is in place.

> 3- Decide whether there are plugins that we would want to have in
>the standard distribution.  I suspect that we will just want 1
>or 2 basic applications as examples.  Or perhaps, plugins
>that are so universally useful for GCC development or users
>that we decide to include them.

I think examples are needed - but we should remember that plugins are 
likely to be slower than code linked directly into GCC (if they need to be 
built as PIC) and may well have host portability issues for a while and so 
I'd expect most generally useful code to continue to be linked in 
directly.  Of course it might well use exactly the same interfaces as 
plugins internally when linked into GCC.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC Plug-in Framework ready to port

[Joseph S. Myers]

On Sat, 31 Jan 2009, Taras Glek wrote:

> One simple and useful plugin could be a per-function warning suppressor. ie
> functions flagged with user(no-warn-unused-variable) could suppress a
> particular false warning.

I don't really think it makes sense for this to be a plugin; it's generic 
infrastructure tightly integrated with the existing "#pragma GCC 
diagnostic" (the right approach would be to make that pragma work in the 
cases it's presently documented not to work reliably, and the basic 
approach discussed in the past is to keep track of enabled or disabled 
diagnostics for ranges of mapped locations).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Creating imaginary inf/nan in GCC

[Joseph S. Myers]

On Sat, 31 Jan 2009, Kaveh R. Ghazi wrote:

> From: "Joseph S. Myers" 
> 
> > On Thu, 29 Jan 2009, Kaveh R. GHAZI wrote:
> > 
> > > I don't think these results are a bug, rather it's just an artifact of the
> > > way complex multiplcation is done and having these special values in
> > 
> > See bug 24581.  Some aspects are a bug (GCC doesn't handle mixed
> > real/complex arithmetic the way it should), some are the lack of imaginary
> > types (though the only use of imaginary types I know of is this one for
> > building up constants, and no-one on the Power ABI working group could
> > find any implementation for Power Architecture that actually supports
> > imaginary types).
> 
> Thanks for the PR pointer.  I'm going to ask the obvious question, if there's
> an obvious answer please excuse me.  :-)
> 
> Would it be sufficient and correct to treat (0.0 + I) * y as a special case
> for MULT_EXPR and just swap the real and imaginary parts of "y" in the result?

(0.0 + I) * y should definitely be handled as a multiplication complex*y, 
not imaginary*y, in accordance with the standard semantics.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: MIPS64 -msym32 and DWARF2_ADDR_SIZE

[Eric Christopher]

>> So my question is whether the saving in the size of the debug info with
>> -msym32 is really worth the trouble here or should we just start generating
>> 64-bit addresses with -msym32?
>
> Generating 64-bit addresses would be fine with me FWIW.  I'm not sure
> the current behaviour is exactly deliberate; it was probably just
> something I overlooked when adding -msym32.
>
> How about the patch below?  I'll apply it in the next couple of days
> if there are no objections.
>

Looks good to me.

-eric

Plugin API Comments (was Re: GCC Plug-in Framework ready to port)

[Sean Callanan]

1- Agree on a common API and document it in
  http://gcc.gnu.org/wiki/GCC_PluginAPI


So to get the ball rolling, here are some comments on the API as  
documented:


-

(1) register_callback is an unnecessary API.  It's already possible to  
use dlsym() to get a pointer to a symbol in a plug-in.  A plug-in  
could export a function symbol corresponding to each hook it is  
interested in; that way a plug-in would simply have things like


void HOOK_PASS_MANAGER_SETUP(...)

instead of needing to register that callback.  Equivalently, a global  
data structure in the plug-in could map hook UIDs to function  
pointers, giving the same effect.  This latter approach would provide  
very elegant hook versioning.


(2) It would be very nice to be able to store trees between passes;  
right now, our custom version of GCC has a separate garbage-collection  
root for plug-ins so that they can store data between passes.


(3) The -fplugin-arg argument is one way to do arguments.  We do it as

  -ftree-plugin=/path/to/plugin.so:arg=value:arg=value:...

We also have a magic argument called FILE that lets you load arguments  
from a file.


(4) We strongly support the user () GCC attribute.

-

As a second note, we have some debugging tools we could contribute as  
soon as an API is fixed, including a GIMPLE visualizer with GDB  
integration.


We also have a file (called parameter.def) which formalizes the macros  
that are valid for each type of GIMPLE tree node.  We use this .def  
file extensively when handling trees in a generic way (such as for  
pretty-printing).


Sincerely,
Sean Callanan