Re: [c++]pt.c:most_specialized_class appears to substitute outer args for inner params

[Larry Evans]

On 11/02/09 22:39, Larry Evans wrote:

The following code around trunk/gcc/cp/pt.c:15514:

15513 partial_spec_args = INNERMOST_TEMPLATE_ARGS (partial_spec_args);
15514 partial_spec_args = tsubst_template_args
15515   (partial_spec_args, outer_args, tf_none, NULL_TREE);

as shown here:

http://gcc.gnu.org/viewcvs/trunk/gcc/cp/pt.c?view=markup&pathrev=153822

appears to substitute outer_args in the place where inner parameters
are located.  Am I reading the code wrong?  I ask because gdb seems to
show this happening with the following code:

--{-- test code --
  struct
outer_arg0
;
  struct
inner_arg0
;
  struct
inner_arg1
;

//#define CLASS_SCOPE_SPECIALIZATION
  template
  < class OuterArg0
  >
  struct
outer_tmpl
{
  template
  < typename InnerArg0
  , typename InnerArg1
  >
  struct
inner_tmpl
  #ifndef CLASS_SCOPE_SPECIALIZATION
;
  #else
{};
  template
  < typename InnerArg0
  >
  struct
inner_tmpl
  < InnerArg0
  , inner_arg1
  >
{
typedef
  InnerArg0
inner_typdef
;
};
  #endif
};

#ifndef CLASS_SCOPE_SPECIALIZATION
  template
  < //class OuterArg0
  >
  template
  < typename InnerArg0
  >
  struct
outer_tmpl
  < outer_arg0
  >::
inner_tmpl
  < InnerArg0
  , inner_arg1
  >
{
typedef
  InnerArg0
inner_typdef
;
};
#endif

typedef
  outer_tmpl
  ::inner_tmpl
  < inner_arg0
  , inner_arg1
  >
  ::inner_typdef //error here.
outer_inner_type
;
--}-- test code --

[snip]
Just adding an outer_tmpl specialization solves the problem:

  template
  
  struct
outer_tmpl
  < outer_arg0
  >
{
  template
  < typename InnerArg0
  , typename InnerArg1
  >
  struct
inner_tmpl
;
};

RE: Understanding IRA

[Ian Bolton]

Yesterday, I wrote:
> BTW, today I have achieved some good results with existing IRA by doing
> the following:
> 
> 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out before
> BOTTOM_REGS.  My previous hacked version worked by increasing the
> priority of those that wanted BOTTOM_REGS, so they got first pick; this
> new version makes them wait their turn, but ensures those with higher
> priority take TOP_CREGS before BOTTOM_REGS.
> 
> The analogy, I think, is of giving out meals on an airplane.  Most
> people will eat meat or vegetarian meals, whereas vegetarians only
> want vegetarian meals.  My hacked version was effectively allowing
> the vegetarians to push to the front of the queue and get their meals;
> this new version works by encouraging the meat eaters to eat the meaty
> meals first, leaving more suitable meals for the vegetarians further
> down the plane.
> 
> 2) I have forced propagation of allocnos to parent regions with the
> following hack in find_allocno_class_costs():
> 
> {
>   /* Propagate costs to upper levels in the region
>  tree.  */
>   parent_a_num = ALLOCNO_NUM (parent_a);
>   for (k = 0; k < cost_classes_num; k++)
> COSTS_OF_ALLOCNO (total_costs, parent_a_num)->cost[k]
>   += COSTS_OF_ALLOCNO (total_costs, a_num)->cost[k];
>   COSTS_OF_ALLOCNO (total_costs, parent_a_num)->mem_cost
> += COSTS_OF_ALLOCNO (total_costs, a_num)->mem_cost;
>   /* BEGIN IGB-IRA CHANGE 2 */
>   /* Force total_costs to propagate upwards, by setting
>  allocno_costs to be total_costs */
>   for (k = 0; k < cost_classes_num; k++)
> COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)->cost[k]
>   = COSTS_OF_ALLOCNO (total_costs, parent_a_num)->cost[k];
> COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)->mem_cost
>   = COSTS_OF_ALLOCNO (total_costs, parent_a_num)->mem_cost;
>   /* END IGB-IRA CHANGE 2 */
> }
> 
> I don't know why propagation isn't happening normally, but
> this total_costs hack achieves the same thing for me at the
> moment.  Is there any information I could provide to help
> someone tell me why propagation isn't happening?

Good news!  I have been able to remove my "total_costs" hack
above by instead commenting out the following line from ira_build()
in ira-build.c:

  remove_unnecessary_regions (false);

For my situation at least, this function is preventing the
propagation of useful allocno information from region 1 to
region 0.  Without my change, the allocation for a pseudo in
region 0 is not aware of how that pseudo will be used inside
a loop in region 1; the real impact of this is that we need
to then do a register move *inside the loop* into a valid
register class for the instruction in region 1.

I do not believe this will impact anyone with a regular
register set, but for any architecture where some instructions
can only use a subset of the register bank, I believe that
all regions are always necessary, since cost information
for each allocno is relevant and important.

I still need to do some more testing in regards this "fix",
but I wanted to put my findings out there as soon as possible
for comment from the experts.

Re: Understanding IRA

[Jeff Law]

On 11/11/09 08:18, Ian Bolton wrote:


Good news!  I have been able to remove my "total_costs" hack
above by instead commenting out the following line from ira_build()
in ira-build.c:

   remove_unnecessary_regions (false);
   
Which is probably an indication of a problem elsewhere.  However, it's 
definitely a good find in that you can put the two compilers side by 
side and debug them to figure out why calling this function inhibits 
propagation.;




I do not believe this will impact anyone with a regular
register set, but for any architecture where some instructions
can only use a subset of the register bank, I believe that
all regions are always necessary, since cost information
for each allocno is relevant and important.
   
FWIW, almost every chip has certain irregularities in their register 
set, so improvements in how the irregularities are handled is definitely 
a good thing across the board.


jeff

Strange optimisation problem - gcc 4.3.2

[Mark Cave-Ayland]

Hi everyone,

I've been looking at adding some code to a performance-critical section 
of OpenBIOS, and I'm quite confused by how some of the changes I am 
making are affecting the overall performance.


For a benchmark, I am using a recursive fibonacci function to test the 
effect of any changes that I have made. The test machines is an Intel 
Core 2 x86 running under a 64-bit Debian Lenny installation.


Firstly, here are the benchmark results running from the unmodified SVN 
source tree:



bu...@zeno:~/src/openbios/openbios-devel$ time echo "28 fib-rec u. bye" 
| ./obj-x86/openbios-unix ./obj-x86/openbios-x86.dict

Welcome to OpenBIOS v1.0 built on Nov 9 2009 17:12
  Type 'help' for detailed information

[unix] Booting default not supported.

0 > 28 fib-rec u. bye 6197ecb
Farewell!

 ok

real0m37.946s
user0m37.178s
sys 0m0.020s


I then add a simple C function pointer below to the top of the forth 
kernel file (which is currently not referenced by any other code changes):



void (*debughook) (void);


If I then re-build and re-run the same benchmark, the results now look 
like this:



bu...@zeno:~/src/openbios/openbios-devel$ time echo "28 fib-rec u. bye" 
| ./obj-x86/openbios-unix ./obj-x86/openbios-x86.dict

Welcome to OpenBIOS v1.0 built on Nov 9 2009 17:17
  Type 'help' for detailed information

[unix] Booting default not supported.

0 > 28 fib-rec u. bye 6197ecb
Farewell!

 ok

real0m52.564s
user0m52.027s
sys 0m0.012s


So I'm really confused as to how adding a simply function pointer in the 
global declaration section (without even adding any code to reference 
it) suddenly incurs an extra 40% overhead? Can anyone explain why this 
is, and/or point me to any suitable gcc optimisation guides?


For reference, the gcc compiler is gcc 4.3.2 under Debian Lenny and the 
compile flags are:


-Os -g -Wall -Wredundant-decls -Wshadow -Wpointer-arith
-Wstrict-prototypes -Wmissing-declarations -Wundef -Wendif-labels 
-Wstrict-aliasing -Wwrite-strings -Wmissing-prototypes



Many thanks,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

native x86_64-w64-mingw32 fails to boostrap

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

cause are the generated scripts as and collect-ld in the gcc diretory.
After building the stage 1 compiler the configuration of libgcc fails.

configure:3019: /home/rainer/tmp/build/./gcc/xgcc
- -B/home/rainer/tmp/build/./gcc/
- -L/home/rainer/tmp/install/x86_64-w64-mingw32/lib
- -L/home/rainer/tmp/install/mingw/lib -isystem
/home/rainer/tmp/install/x86_64-w64-mingw32/include -isystem
/home/rainer/tmp/install/mingw/include
- -B/home/rainer/tmp/install/x86_64-w64-mingw32/bin/
- -B/home/rainer/tmp/install/x86_64-w64-mingw32/lib/ -isystem
/home/rainer/tmp/install/x86_64-w64-mingw32/include -isystem
/home/rainer/tmp/install/x86_64-w64-mingw32/sys-include
- -L/home/rainer/tmp/build/./ld-o conftest -g -O2   conftest.c  >&5
D:\phoenix\bin\sh.exe: *** fork: can't reserve memory for stack 0x4D -
0x6D, Win32 error 0
  0 [main] sh" 5452 sync_with_child: child 4404(0x234) died before
initialization with status code 0x1
710 [main] sh" 5452 sync_with_child: *** child state waiting for longjmp
D:/MSYS/home/rainer/tmp/build/gcc/as: fork: Resource temporarily unavailable

The only way to boostrap a native *mingw32 compiler is using msys. For
i686-w64-mingw32 that works excellent.

For x86_64-w64-mingw32the situation is different. We have a 64bit stage 1
compiler which invokes as and ld through the mentioned scripts which are
executed by a 32bit shell which calls the 64bit as or ld.
AFAIK, this in't going to work!

Any ideas?

Rainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr66fUACgkQoUhjsh59BL7ERwCZAScKbRMlM7gXq8Rkpe0IbQxi
+jgAnjvC1UEUy+W0eTpWXRNLBXd9tZgR
=pZug
-END PGP SIGNATURE-

Re: libtool update?

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralf Wildenhues schrieb:
> Hello Rainer,
> 
> * Rainer Emrich wrote on Tue, Aug 18, 2009 at 04:08:38PM CEST:
>> Are there any plans to update libtool?
> 
> If anybody updates libtool before the Autoconf + Automake update,
> I'm probably going to run screaming.
> 
> Afterwards you can go crazy all you like.
> 
>> There is at least one issue which is solved upstream, see
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972
> 
> There is at least one other issue solved upstream which you reported.
> 
> There is at least one other issue (-bindir) pending upstream which would
> be nice to have solved in GCC.
> 
> Cheers,
> Ralf
> 
Any news on libtool? Does anybody care to update?

Cheers,
Rainer

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr66pEACgkQoUhjsh59BL403wCgyOG4J51seIYbUAdySGP3LMO7
a3AAn1h4oCA3LNZ0MBmvglDlAjVOqF9p
=1KEa
-END PGP SIGNATURE-

Re: Understanding IRA

[Vladimir Makarov]

Ian Bolton wrote:

Yesterday, I wrote:
  

BTW, today I have achieved some good results with existing IRA by doing
the following:

1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out before
BOTTOM_REGS.  My previous hacked version worked by increasing the
priority of those that wanted BOTTOM_REGS, so they got first pick; this
new version makes them wait their turn, but ensures those with higher
priority take TOP_CREGS before BOTTOM_REGS.

The analogy, I think, is of giving out meals on an airplane.  Most
people will eat meat or vegetarian meals, whereas vegetarians only
want vegetarian meals.  My hacked version was effectively allowing
the vegetarians to push to the front of the queue and get their meals;
this new version works by encouraging the meat eaters to eat the meaty
meals first, leaving more suitable meals for the vegetarians further
down the plane.

2) I have forced propagation of allocnos to parent regions with the
following hack in find_allocno_class_costs():

{
  /* Propagate costs to upper levels in the region
 tree.  */
  parent_a_num = ALLOCNO_NUM (parent_a);
  for (k = 0; k < cost_classes_num; k++)
COSTS_OF_ALLOCNO (total_costs, parent_a_num)->cost[k]
  += COSTS_OF_ALLOCNO (total_costs, a_num)->cost[k];
  COSTS_OF_ALLOCNO (total_costs, parent_a_num)->mem_cost
+= COSTS_OF_ALLOCNO (total_costs, a_num)->mem_cost;
  /* BEGIN IGB-IRA CHANGE 2 */
  /* Force total_costs to propagate upwards, by setting
 allocno_costs to be total_costs */
  for (k = 0; k < cost_classes_num; k++)
COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)->cost[k]
  = COSTS_OF_ALLOCNO (total_costs, parent_a_num)->cost[k];
COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)->mem_cost
  = COSTS_OF_ALLOCNO (total_costs, parent_a_num)->mem_cost;
  /* END IGB-IRA CHANGE 2 */
}

I don't know why propagation isn't happening normally, but
this total_costs hack achieves the same thing for me at the
moment.  Is there any information I could provide to help
someone tell me why propagation isn't happening?



Good news!  I have been able to remove my "total_costs" hack
above by instead commenting out the following line from ira_build()
in ira-build.c:

  remove_unnecessary_regions (false);

For my situation at least, this function is preventing the
propagation of useful allocno information from region 1 to
region 0.  Without my change, the allocation for a pseudo in
region 0 is not aware of how that pseudo will be used inside
a loop in region 1; the real impact of this is that we need
to then do a register move *inside the loop* into a valid
register class for the instruction in region 1.

I do not believe this will impact anyone with a regular
register set, but for any architecture where some instructions
can only use a subset of the register bank, I believe that
all regions are always necessary, since cost information
for each allocno is relevant and important.

I still need to do some more testing in regards this "fix",
but I wanted to put my findings out there as soon as possible
for comment from the experts.
  
The function (remove_unnecessary_regions) is used to increase RA speed 
by decreasing number of regions.  The region is removed if the register 
pressure is not high in the region in other words if the probability to 
spill pseudos on the region border to improve RA in the region is small.


But when the region is removed and correspondingly allocnos (see 
function remove_unecessary_allocnos) in the region the info including 
hard register costs is propagated to the  corresponding allocnos in the 
parent region (see function propagate_some_info_from_allocno).


I've just checked the code it looks ok to me.  Ian, it would be nice if 
you figure out why the propagation does not happen.   As Jeff wrote, 
fixing that would be important practically for any target.

The Linux binutils 2.20.51.0.3 is released

[H.J. Lu]

This is the beta release of binutils 2.20.51.0.3 for Linux, which is
based on binutils 2009 1109 in CVS on sourceware.org plus various
changes. It is purely for Linux.

All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.

You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd.  By
default, ld.bfd will be installed as ld.  You can use the configure
option, --enable-linker=[bfd,gold] to choose the default linker, ld.
IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both --enable-plugins.

Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts

fnstsw %eax

fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use

fnstsw %ax

Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.

For

.data.init_task : { *(.data.init_task) }

LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use

.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }

to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior.  You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.

The new x86_64 assembler no longer accepts

monitor %eax,%ecx,%edx

You should use

monitor %rax,%ecx,%edx

or
monitor

which works with both old and new x86_64 assemblers. They should
generate the same opcode.

The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,

movl (%eax),%ds
movl %ds,(%eax)

To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,

mov (%eax),%ds
mov %ds,(%eax)

should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support

movw (%eax),%ds
movw %ds,(%eax)

without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at

http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch

The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add

ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif

to arch/ia64/Makefile in your kernel source tree.

Please report any bugs related to binutils 2.20.51.0.3 to
hjl.to...@gmail.com

and

http://www.sourceware.org/bugzilla/

Changes from binutils 2.20.51.0.2:

1. Update from binutils 2009 1109.
2. Fix "ld -s -static" with STT_GNU_IFUNC symbols.  PR 10911.
3. Fix file permission on PIE with objcopy. PR 10802.
4. Fix x86 Intel syntax assembler with relocation.  PR 10856.
5. Fix x86 Intel syntax assembler with far jump.  PR 10740.
6. Add AMD LWP support.
7. Renamed linker option --add-needed to --copy-dt-needed-entries.
8. Support enabling both ld and gold with --enable-gold=both and
--enable-linker=[bfd,gold].
9. Improve gold.
10. Improve arm support.
11. Improve cris support.
12. Improve hppa support.
13. Improve m68k support.
14. Improve RX support.
15. Improve spu support.
16. Improve vax support.
17. Improve MacOS support.
18. Improve Windows support.

Changes from binutils 2.20.51.0.1:

1. Update from binutils 2009 1009.
2. Add .cfi_sections to assembler.
3. Fix a linker bug with local dynamic symbols. PR 10630.
4. Add DWARF-3/DWARF-4 support.
5. Fix the x86 assembler PIC bug. PR 10677.
6. Fix the x86-64 displacement assembler bug.  PR 10636.
7. Fix the x86 assembler bug with Intel memory syntax.  PR 10637.
8. Fix the x86 PIC assembler bug with Intel syntax. PR 10704.
9. Add RX support.
10. Improve gold.
11. Improve arm support.
12. Improve bfin support.
13. Improve cr16 support.
14. Improve m68k support.
15. Improve mips support.
16. Improve ppc support.

Changes from binutils 2.19.51.0.14:

1. Update from binutils 2009 0905.
2. Add Intel L1OM support.
3. Add MicroBlaze support.
4. Fix assembler for DWARF info without .file/.loc directives.  PR 10531.
5. Improve -pie with TLS relocations on ia32 and x86-64.  PRs 6443/10434.
6. Fix linker page size support.  PR 10569.
7. Fix wildcard in linker version script.  PR 10518.
8. Fix strip with STB_GNU

Re: gccgo: A gcc frontend for Go, a new programming language

[Frank Ch. Eigler]

Ian Lance Taylor  writes:

> [...]  Go, a new experimental systems programming language designed
> by a small group at Google.  [...]  The frontend is written in, yes,
> C++. [...]

Neat.  Are there any plans to have a front-end written in its own
language (and use the current C++ one only for bootstrapping)?

- FChE

RE: Understanding IRA

[Ian Bolton]

Vladimir Makarov wrote:
> Ian Bolton wrote:
> > Yesterday, I wrote:
> >
> >> BTW, today I have achieved some good results with existing IRA by
> doing
> >> the following:
> >>
> >> 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out
> before
> >> BOTTOM_REGS.  My previous hacked version worked by increasing the
> >> priority of those that wanted BOTTOM_REGS, so they got first pick;
> this
> >> new version makes them wait their turn, but ensures those with
> higher
> >> priority take TOP_CREGS before BOTTOM_REGS.
> >>
> >> The analogy, I think, is of giving out meals on an airplane.  Most
> >> people will eat meat or vegetarian meals, whereas vegetarians only
> >> want vegetarian meals.  My hacked version was effectively allowing
> >> the vegetarians to push to the front of the queue and get their
> meals;
> >> this new version works by encouraging the meat eaters to eat the
> meaty
> >> meals first, leaving more suitable meals for the vegetarians further
> >> down the plane.
> >>
> >> 2) I have forced propagation of allocnos to parent regions with the
> >> following hack in find_allocno_class_costs():
> >>
> >> {
> >>   /* Propagate costs to upper levels in the region
> >>  tree.  */
> >>   parent_a_num = ALLOCNO_NUM (parent_a);
> >>   for (k = 0; k < cost_classes_num; k++)
> >> COSTS_OF_ALLOCNO (total_costs, parent_a_num)->cost[k]
> >>   += COSTS_OF_ALLOCNO (total_costs, a_num)->cost[k];
> >>   COSTS_OF_ALLOCNO (total_costs, parent_a_num)->mem_cost
> >> += COSTS_OF_ALLOCNO (total_costs, a_num)->mem_cost;
> >>   /* BEGIN IGB-IRA CHANGE 2 */
> >>   /* Force total_costs to propagate upwards, by setting
> >>  allocno_costs to be total_costs */
> >>   for (k = 0; k < cost_classes_num; k++)
> >> COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)->cost[k]
> >>   = COSTS_OF_ALLOCNO (total_costs, parent_a_num)->cost[k];
> >> COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)->mem_cost
> >>   = COSTS_OF_ALLOCNO (total_costs, parent_a_num)->mem_cost;
> >>   /* END IGB-IRA CHANGE 2 */
> >> }
> >>
> >> I don't know why propagation isn't happening normally, but
> >> this total_costs hack achieves the same thing for me at the
> >> moment.  Is there any information I could provide to help
> >> someone tell me why propagation isn't happening?
> >>
> >
> > Good news!  I have been able to remove my "total_costs" hack
> > above by instead commenting out the following line from ira_build()
> > in ira-build.c:
> >
> >   remove_unnecessary_regions (false);
> >
> > For my situation at least, this function is preventing the
> > propagation of useful allocno information from region 1 to
> > region 0.  Without my change, the allocation for a pseudo in
> > region 0 is not aware of how that pseudo will be used inside
> > a loop in region 1; the real impact of this is that we need
> > to then do a register move *inside the loop* into a valid
> > register class for the instruction in region 1.
> >
> > I do not believe this will impact anyone with a regular
> > register set, but for any architecture where some instructions
> > can only use a subset of the register bank, I believe that
> > all regions are always necessary, since cost information
> > for each allocno is relevant and important.
> >
> > I still need to do some more testing in regards this "fix",
> > but I wanted to put my findings out there as soon as possible
> > for comment from the experts.
> >
> The function (remove_unnecessary_regions) is used to increase RA speed
> by decreasing number of regions.  The region is removed if the register
> pressure is not high in the region in other words if the probability to
> spill pseudos on the region border to improve RA in the region is
> small.
> 
> But when the region is removed and correspondingly allocnos (see
> function remove_unecessary_allocnos) in the region the info including
> hard register costs is propagated to the  corresponding allocnos in the
> parent region (see function propagate_some_info_from_allocno).
> 
> I've just checked the code it looks ok to me.  Ian, it would be nice if
> you figure out why the propagation does not happen.   As Jeff wrote,
> fixing that would be important practically for any target.

(I'm in the middle of a hefty compile at the moment, so I can't do any
more debugging yet, but I figured I'd think out loud on this list in the
mean time.)

At first, I thought the problem was that propagate_some_info_from_allocno()
appears to only pass up information about the cover class, as opposed
to every cost_class (which was what my total_costs hack did).  However, I see
that the propagate_allocno_info() function, which is now being called when
I comment out remove_unnecessary_regions(), also only passes up information
about the cover class, so I don't think it's propagation that's the issue.

Looking at ira_build(), I see that there is a call to create_caps() just
after the call to propagate_allocno_info() - both of which were guarded by
the condition more_one_

Re: gccgo: A gcc frontend for Go, a new programming language

[Basile STARYNKEVITCH]

Frank Ch. Eigler wrote:

Ian Lance Taylor  writes:


[...]  Go, a new experimental systems programming language designed
by a small group at Google.  [...]  The frontend is written in, yes,
C++. [...]


Neat.  Are there any plans to have a front-end written in its own
language (and use the current C++ one only for bootstrapping)?



My feeling is that Google's Go (quite a nice language from the slides I just have read) is almost "canonically" the case 
for a front-end plugin.


That is, gccgo could be the following shellscript
  #! /bin/sh
  gcc -fplugin=gofrontend.so $*
and of course we need to add into gcc-4.5 the few plugin hooks to make that 
easy.

Regards.


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

Creating a function dynamically

[Taro Okumichi]

I am hacking in the gcc code and come to a point where I cant come
any further: I want to expand the "-finstrument-functions" to create a dynamic
dump function in the background, instead of  calling a fixed
__cyg_profile_func_enter/exit
I.e:
 if I have
 f1(int a,int b) { }
 I would like to create a dynamic function
 _trace_f1(int a,int b) {
   __trace_int(a);
   __trace_int(b);
 }

I apended the code I use below. the function
gimplify_create_trace_func (shown below) is
called from:

gimplify_function_tree (tree fndecl)->
 gimplify_create_trace_func(fndecl,"_trace_f1");


These are the steps I do in gimplify_create_trace_func():

1. Build function definition for _trace_f1:   build_decl
(FUNCTION_DECL, get_identifier (n), fntyp);
2. Declare function parameters for "a" and "b": build_decl (PARM_DECL,
get_identifier (argname), TREE_TYPE(param));
3. Output each parameter:  build_function_call_expr (trace ,
thisparaml );
  where "thisparaml" is "a" or "b" and trace is a external function
ref repending on the typ:

The problem now is this:
The assembler output is:

_trace_f1:
   pushl   %ebp
   movl%esp, %ebp
   subl$8, %esp
   movl$0, (%esp)
   call__trace__int
   movl$0, (%esp)
   call__trace__int
   leave
   ret

whereas I would expect:

_trace_f1:
   pushl   %ebp
   movl%esp, %ebp
   subl$8, %esp
   movl8(%ebp), %eax
   movl%eax, (%esp)
   call__trace__int
   movl12(%ebp), %eax
   movl%eax, (%esp)
   call__trace__int
   ...

Can anyone tell me what I am doing wrong. The compiler oututs
__trace__int(0) instead of using the function parameter as an argument:
 _trace_f1(int a,int b) {
   __trace_int(a);
  ...

Or can somebody point me to a codesnippet in  gcc that
does the same (create functions dynamically on the fly) so
I can  take a look and learn...


Greetings



--- create a dynamic funtion 

void
gimplify_create_trace_func (tree fndecl, char *n)
{
   int i;
   tree body = NULL;
   tree ir, prev, param, fn, fntyp, parm, tdef, argstyp =
NULL_TREE, argslist = NULL_TREE ;
   char argname[256];

   /* create function type */
   for (i = 0,param = DECL_ARGUMENTS (fndecl); param ; i++,param
=TREE_CHAIN (param)) {
   argstyp = tree_cons (NULL_TREE, TREE_TYPE(param), argstyp);
   }
   if (argstyp == NULL_TREE)
   argstyp = void_list_node;
   else {
   tree last = argstyp;
   argstyp = nreverse (argstyp);
   TREE_CHAIN (last) = void_list_node;
   }
   fntyp = build_function_type (void_type_node, argstyp);

   /* build function prototype */
   fn = build_decl (FUNCTION_DECL, get_identifier (n), fntyp);

   pushdecl (fn);

   prev = current_function_decl;
   current_function_decl = fn;

   push_scope();
   declare_parm_level ();

   /* build function argument list */
   for (i = 0,param = DECL_ARGUMENTS (fndecl); param ; i++,param
=TREE_CHAIN (param)) {
   tree argdecl;
   sprintf(argname,"a%d",i);
   argdecl = build_decl (PARM_DECL, get_identifier
(argname), TREE_TYPE(param));
   argslist = chainon (argdecl, argslist);
   printf("decl:%x\n",argdecl);
   pushdecl(argdecl);
   DECL_ARTIFICIAL(argdecl) = 1;


   /* if (DECL_NAME (argdecl)) { */
   /*  bind (DECL_NAME (decl), decl, current_scope, */
   /*/\*invisible=*\/false, /\*nested=*\/false); */
   /* } */

   DECL_CONTEXT (argdecl) = fn;
   }
   argslist = nreverse (argslist);
   DECL_ARGUMENTS (fn) = argslist;


   ir = build_decl (RESULT_DECL, NULL_TREE, void_type_node);
   DECL_CONTEXT (ir) = fn;
   DECL_ARTIFICIAL (ir) = 1;
   DECL_IGNORED_P (ir) = 1;
   DECL_RESULT (fn) = ir;


   TREE_STATIC (fn) = 0;
   TREE_USED (fn) = 1;
   DECL_ARTIFICIAL (fn) = 1;
   DECL_IGNORED_P (fn) = 1;
   DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (fn) = 1;

   allocate_struct_function (fn);

   if (tracetype == trace_out_none) {

   DECL_SAVED_TREE (fn) = build_empty_stmt();

   } else if (tracetype == trace_out_all) {

   tree thisp, stmts;

   stmts = alloc_stmt_list();

   /* output one call for each argument */
   for (i = 0,thisp = argslist, param = DECL_ARGUMENTS
(fndecl); param; i++,thisp = TREE_CHAIN (thisp), param =TREE_CHAIN
(param)) {
   tree trace, thisparaml = NULL, x;
   char *name =
gen_aux_info_type_str_canonical(TREE_TYPE(param));
   name = concat("__trace__", name, NULL);
   fprintf(stderr, "typ: \"%s\" \n", name);

   trace = build_function_type_list
(void_type_node, TREE_TYPE(thisp

Re: libtool update?

[Ralf Wildenhues]

Hello Rainer,

* Rainer Emrich wrote on Wed, Nov 11, 2009 at 05:47:13PM CET:
> Any news on libtool? Does anybody care to update?

Work in progress:


Since then, I found a couple of issues, one of which was a
bug in the sync and the other I'm not yet sure whether it
is a GCC configury or Libtool upstream bug.

I hope to get to it within the next couple of weekends,
but I'm swamped ATM (of course won't mind being beaten
to if someone feels so inclined).

Cheers,
Ralf

RE: Understanding IRA

[Ian Bolton]

Ian Bolton wrote:
> Vladimir Makarov wrote:
> > Ian Bolton wrote:
> > > Yesterday, I wrote:
> > >
> > >> BTW, today I have achieved some good results with existing IRA by
> > doing
> > >> the following:
> > >>
> > >> 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out
> > before
> > >> BOTTOM_REGS.  My previous hacked version worked by increasing the
> > >> priority of those that wanted BOTTOM_REGS, so they got first pick;
> > this
> > >> new version makes them wait their turn, but ensures those with
> > higher
> > >> priority take TOP_CREGS before BOTTOM_REGS.
> > >>
> > >> The analogy, I think, is of giving out meals on an airplane.  Most
> > >> people will eat meat or vegetarian meals, whereas vegetarians only
> > >> want vegetarian meals.  My hacked version was effectively allowing
> > >> the vegetarians to push to the front of the queue and get their
> > meals;
> > >> this new version works by encouraging the meat eaters to eat the
> > meaty
> > >> meals first, leaving more suitable meals for the vegetarians
> further
> > >> down the plane.
> > >>
> > >> 2) I have forced propagation of allocnos to parent regions with
> the
> > >> following hack in find_allocno_class_costs():
> > >>
> > >> {
> > >>   /* Propagate costs to upper levels in the region
> > >>  tree.  */
> > >>   parent_a_num = ALLOCNO_NUM (parent_a);
> > >>   for (k = 0; k < cost_classes_num; k++)
> > >> COSTS_OF_ALLOCNO (total_costs, parent_a_num)->cost[k]
> > >>   += COSTS_OF_ALLOCNO (total_costs, a_num)->cost[k];
> > >>   COSTS_OF_ALLOCNO (total_costs, parent_a_num)->mem_cost
> > >> += COSTS_OF_ALLOCNO (total_costs, a_num)->mem_cost;
> > >>   /* BEGIN IGB-IRA CHANGE 2 */
> > >>   /* Force total_costs to propagate upwards, by setting
> > >>  allocno_costs to be total_costs */
> > >>   for (k = 0; k < cost_classes_num; k++)
> > >> COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)->cost[k]
> > >>   = COSTS_OF_ALLOCNO (total_costs, parent_a_num)->cost[k];
> > >> COSTS_OF_ALLOCNO (allocno_costs, parent_a_num)->mem_cost
> > >>   = COSTS_OF_ALLOCNO (total_costs, parent_a_num)->mem_cost;
> > >>   /* END IGB-IRA CHANGE 2 */
> > >> }
> > >>
> > >> I don't know why propagation isn't happening normally, but
> > >> this total_costs hack achieves the same thing for me at the
> > >> moment.  Is there any information I could provide to help
> > >> someone tell me why propagation isn't happening?
> > >>
> > >
> > > Good news!  I have been able to remove my "total_costs" hack
> > > above by instead commenting out the following line from ira_build()
> > > in ira-build.c:
> > >
> > >   remove_unnecessary_regions (false);
> > >
> > > For my situation at least, this function is preventing the
> > > propagation of useful allocno information from region 1 to
> > > region 0.  Without my change, the allocation for a pseudo in
> > > region 0 is not aware of how that pseudo will be used inside
> > > a loop in region 1; the real impact of this is that we need
> > > to then do a register move *inside the loop* into a valid
> > > register class for the instruction in region 1.
> > >
> > > I do not believe this will impact anyone with a regular
> > > register set, but for any architecture where some instructions
> > > can only use a subset of the register bank, I believe that
> > > all regions are always necessary, since cost information
> > > for each allocno is relevant and important.
> > >
> > > I still need to do some more testing in regards this "fix",
> > > but I wanted to put my findings out there as soon as possible
> > > for comment from the experts.
> > >
> > The function (remove_unnecessary_regions) is used to increase RA
> speed
> > by decreasing number of regions.  The region is removed if the
> register
> > pressure is not high in the region in other words if the probability
> to
> > spill pseudos on the region border to improve RA in the region is
> > small.
> >
> > But when the region is removed and correspondingly allocnos (see
> > function remove_unecessary_allocnos) in the region the info including
> > hard register costs is propagated to the  corresponding allocnos in
> the
> > parent region (see function propagate_some_info_from_allocno).
> >
> > I've just checked the code it looks ok to me.  Ian, it would be nice
> if
> > you figure out why the propagation does not happen.   As Jeff wrote,
> > fixing that would be important practically for any target.
> 
> (I'm in the middle of a hefty compile at the moment, so I can't do any
> more debugging yet, but I figured I'd think out loud on this list in
> the
> mean time.)
> 
> At first, I thought the problem was that
> propagate_some_info_from_allocno()
> appears to only pass up information about the cover class, as opposed
> to every cost_class (which was what my total_costs hack did).  However,
> I see
> that the propagate_allocno_info() function, which is now being called
> when
> I comment out remove_unnecessary_regions(), also only passes up
> information

Re: gccgo: A gcc frontend for Go, a new programming language

[Joseph S. Myers]

On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote:

> My feeling is that Google's Go (quite a nice language from the slides I just
> have read) is almost "canonically" the case for a front-end plugin.

Well, if you really wish to impede host portability in several different 
ways.

* Use of a plugin drops portability to all non-ELF hosts.

> That is, gccgo could be the following shellscript

* Use of a shell script for an installed tool drops portability to MinGW 
hosts (see recent discussion of how while using MinGW as a *build* system 
is a pain because of all the other infrastructure needed to support shell 
scripts and other tools for the build, it works fine as a *host*).

>   #! /bin/sh
>   gcc -fplugin=gofrontend.so $*

* Use of $* drops support for file names with spaces in (and various other 
cases), use "$@".

(Note: I have not looked at whether there are in fact host or target 
portability issues with the present implementation.)

I'm sure GNU/Linux distributors would find it useful to be able to build 
front ends separately from GCC rather than needing to patch in several 
different out-of-tree front ends.  But plugins (in the .so sense, as 
opposed to dropping in another executable alongside cc1 etc. and providing 
the objects needed to build such executables) may not be the best approach 
for that (rather, I'd imagine per-language specs potentially being read 
from a file by the driver).  And users *should* be able to use just the 
"gcc" driver for all languages rather than needing separate drivers for 
each language, and not need special options for a particular language.

(For some of the less esoteric languages distributors find themselves 
patching in, I'd favour integration in the GCC source tree, but the 
maintainers of the front ends don't generally seem to have been interested 
in that.)

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

Re: gccgo: A gcc frontend for Go, a new programming language

[Joe Buck]

On Wed, Nov 11, 2009 at 11:26:36AM -0800, Basile STARYNKEVITCH wrote:
> My feeling is that Google's Go (quite a nice language from the slides I just 
> have read) is almost "canonically" the case 
> for a front-end plugin.

I have some major concerns about this suggestion.  Isn't this a recipe for
getting people to stop contributing changes to gcc?

You seem to want people to use plugins for everything.  I would prefer to
see more limited uses.  Plugins are appropriate for small, specialized
additions to gcc that aren't generally useful enough, or stable enough, to
include in the main gcc distribution.  For example, a specialized static
checker, or a pass to add an unusual kind of instrumentation, or something
to gather statistics on a body of source code.

They weren't intended as a way of attaching complete new front ends
or complete new back ends.  That was the thing that RMS feared the most,
and he had at least some justification: would we have a C++ compiler or
an Objective-C compiler if the companies who employed the original authors
had the alternative of hooking into GCC without contributing their code?
There's some evidence that they would not have.

We currently lack enough plugin hooks to give a complete front end a
stable interface, and I would argue that this is a feature.

Re: gccgo: A gcc frontend for Go, a new programming language

[Chris Lattner]

On Nov 11, 2009, at 12:43 PM, Joe Buck wrote:



They weren't intended as a way of attaching complete new front ends
or complete new back ends.  That was the thing that RMS feared the  
most,
and he had at least some justification: would we have a C++ compiler  
or
an Objective-C compiler if the companies who employed the original  
authors
had the alternative of hooking into GCC without contributing their  
code?

There's some evidence that they would not have.


I thought it *was* a goal to allow attaching new (GPL3 compatible)  
backends?


-Chris

Re: gccgo: A gcc frontend for Go, a new programming language

[Basile STARYNKEVITCH]

Joe Buck wrote:

On Wed, Nov 11, 2009 at 11:26:36AM -0800, Basile STARYNKEVITCH wrote:
My feeling is that Google's Go (quite a nice language from the slides I just have read) is almost "canonically" the case 
for a front-end plugin.


I have some major concerns about this suggestion.  Isn't this a recipe for
getting people to stop contributing changes to gcc?

You seem to want people to use plugins for everything.  I would prefer to
see more limited uses.  Plugins are appropriate for small, specialized
additions to gcc that aren't generally useful enough, or stable enough, to
include in the main gcc distribution.  For example, a specialized static
checker, or a pass to add an unusual kind of instrumentation, or something
to gather statistics on a body of source code.



My intuitions (perhaps wrong) when posting my initial suggestion have been

* Google Go is still a niche language. And I would guess it is targetted to Linux & Unix variants (because I heard that 
Google does not use Windows on their web-crawling servers, but only Unix variants, mostly Linux). I really feel that a 
niche language is exactly a "small,  specialized addition to gcc that isn't generally useful enough, or stable enough, 
to be included in the main gcc distribution". I would be glad to


* Looking at other niche languages in the past having had a GCC front-end (D, Mercury, perhaps some Modula, or Cobol, or 
Pascal, ...) it seems that most of them are not accepted in the GCC trunk proper. As far as I understand, neither 
gcc-4.4 nor the current trunk can be configured to accept D or Mercury (or any else non-mainstream) langauge. So it 
seems that it is *extremely* difficult to have an experimental language accepted inside GCC core. But I admit I might be 
very wrong, because I don't know of all the details. My feeling (perhaps wrong) is that the GCC community don't care 
much about exotic languages (and that is sadly ok for me), only about very mainstream languages. In addition, some 
existing front-ends in GCC does not seem very used (I never met any person using gcj, and I don't know of many Debian 
packages compiled with it). Several FSF blessed language implementations (GNU Smalltalk, GNU Clisp, the future GNU 
Epsilon) are *not* GCC derived implementations.


* The current GCC trunk still lacks a few hooks for other frontend languages as plugins. I really believe that feature 
would be a good thing (notice that LLVM in contrast was initially designed to be a library usable by front-ends, with 
Clang appearing later). Because I am widely guessing that for people experimenting new languages, making a plugin would 
be a bit easier (assuming it is possible) and more importantly, distributing plugin binaries will hopefully be easier 
than distributing GCC variants. Of course, there will be a plugin mess (this is not avoidable).



* GCC branches & experimental variants are so complex that nobody uses them. This includes GCC variants for exotic 
languages. And even a bit used GCC variants (like D) are lagging w.r.t. to GCC core evolution (AFAIK D is only at GCC 
4.2 level).



I can tell it differently: imagine you are an academic (or a researcher at Google or some big corporation) wanting to 
experiment some new language. Today (end of 2009) you better not base your implementation on GCC (better use LLVM, or 
target some existing bytecode like CIL/C# -as F# does-, Java/JVM as Clojure & Scala do, ...- or build your own VM (as in 
Ocaml), or perhaps generate C code for GCC. We might aim to change that, and make easier to make new GCC front-ends. I 
feel that plugins could help here.


I am indeed hoping that in a couple of years, most systems having GCC installed 
will permit plugins for it.

Of course, we could also not care about GCC supporting strange front-ends.

In addition, plugin extensions required for front-ends will very probably have a lot more success if they are pushed by 
Google people than by random GCC hackers like me.


I do know quite well the Ocaml team, but I won't dare suggesting them to make an Ocaml front-end to GCC. Xavier Leroy 
(the head of Ocaml team at Inria) would rightly laugh at such a suggestion.


Regards.



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

Re: gccgo: A gcc frontend for Go, a new programming language

[Ian Lance Taylor]

f...@redhat.com (Frank Ch. Eigler) writes:

> Ian Lance Taylor  writes:
>
>> [...]  Go, a new experimental systems programming language designed
>> by a small group at Google.  [...]  The frontend is written in, yes,
>> C++. [...]
>
> Neat.  Are there any plans to have a front-end written in its own
> language (and use the current C++ one only for bootstrapping)?

I don't personally have any plans to write the gcc frontend in Go,
though that would be clearly possible.  There are vague plans for a
full compiler written in Go.

Note that there is another Go compiler, gccgo is really more of a
secondary one at this point.

Ian

Re: gccgo: A gcc frontend for Go, a new programming language

[Basile STARYNKEVITCH]

Basile STARYNKEVITCH wrote:


* Google Go is still a niche language. And I would guess it is targetted 
to Linux & Unix variants (because I heard that Google does not use 
Windows on their web-crawling servers, but only Unix variants, mostly 
Linux). I really feel that a niche language is exactly a "small,  
specialized addition to gcc that isn't generally useful enough, or 
stable enough, to be included in the main gcc distribution". I would be 
glad to


I forgot to type "be wrong".

I mean also

"I would be happy if niche languages could be more easily added into GCC core."

But I think nobody wants that. I could guess reasons for not wanting extra front-ends in GCC (the same reasons could 
even perhaps be used to remove rarely used front-ends like Objective-C++ from future GCC). But I also think that


Regards

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

Invitation avant-première

[Rotary espoir en tête]

Bonjour,

Nous vous proposons de découvrir en avant-première le dernier Disney, « Le
drôle de Noël de Scrooge » avec Jim Carrey,

De faire avancer la recherche sur les maladies du cerveau,

De faire plaisir à vos collaborateurs et à vos clients… 

Et de découvrir le Rotary !

C'est une initiative des 1 035 Rotary clubs de France qui avec leurs 4
éditions précédentes ont déjà permis de recueillir près de 3 millions
d’euros, totalement attribués au financement de matériel nécessaire à la
recherche.

 
Dès à présent, réservez le nombre de places que vous souhaitez et
participez ainsi à cette mobilisation nationale !

En vous remerciant de votre réponse au présent courrier. 

Une facture ou un reçu fiscal vous sera établi à votre demande pour tout
don de 150€, équivalent à 10 places.

Pour tout renseignement et envoi de dons, contactez :

Mr TUMER  , 233 rue du Faubourg Saint Martin 75010 Paris
Tél : 06 74 19 35 16  Email : contact-rot...@myreso.fr

Pour plus d'information sur l'opération: http://www.espoir-en-tete.org/

Pour plus d'information sur le Rotary: http://www.rotary-paris-nord.fr/

Pour ne plus recevoir de mail de notre part, cliquez sur le lien ci-dessous:
http://ml.myreso.fr/form.php?1651d7ca755f7fb42d1e

Re: gccgo: A gcc frontend for Go, a new programming language

[Joseph S. Myers]

On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote:

> * Looking at other niche languages in the past having had a GCC front-end (D,
> Mercury, perhaps some Modula, or Cobol, or Pascal, ...) it seems that most of
> them are not accepted in the GCC trunk proper. As far as I understand, neither
> gcc-4.4 nor the current trunk can be configured to accept D or Mercury (or any
> else non-mainstream) langauge. So it seems that it is *extremely* difficult to
> have an experimental language accepted inside GCC core. But I admit I might be

No, it's not difficult.  The basic requirement is that the maintainers of 
the front end, or someone with the interest and ability to maintain a fork 
of it (as with gfortran originating based on g95), actually want to 
include it in GCC and do the development in the GCC context (and of course 
that the legal requirements are met regarding assignments).  We last had 
discussions of Pascal integration in March 2005, and the others haven't 
even got to the point of someone expressing an interest in integrating it; 
and the basic requirement for any front end or back end to be integrated 
is that it gets submitted by someone willing to be a maintainer for it in 
GCC.

If maintainers want to work in the GCC context and have their front ends 
become a full part of GCC on the same level and under the same rules as 
other front ends, I expect their front ends to be accepted, even those for 
fairly obscure languages (we had a CHILL front end for a while).  I don't 
think any of those you mention have been rejected, just not submitted.

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

Re: gccgo: A gcc frontend for Go, a new programming language

[Basile STARYNKEVITCH]

Joseph S. Myers wrote:

On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote:


* Looking at other niche languages in the past having had a GCC front-end (D,
Mercury, perhaps some Modula, or Cobol, or Pascal, ...) it seems that most of
them are not accepted in the GCC trunk proper. 




No, it's not difficult.  The basic requirement is that the maintainers of 
the front end, or someone with the interest and ability to maintain a fork 
of it (as with gfortran originating based on g95), actually want to 
include it in GCC and do the development in the GCC context (and of course 
that the legal requirements are met regarding assignments).  We last had 
discussions of Pascal integration in March 2005, and the others haven't 
even got to the point of someone expressing an interest in integrating it; 
and the basic requirement for any front end or back end to be integrated 
is that it gets submitted by someone willing to be a maintainer for it in 
GCC.


If maintainers want to work in the GCC context and have their front ends 
become a full part of GCC on the same level and under the same rules as 
other front ends, I expect their front ends to be accepted, even those for 
fairly obscure languages (we had a CHILL front end for a while).  I don't 
think any of those you mention have been rejected, just not submitted.


This is a very interesting information.

But I feel that as a community we can understand it as both a half-full or a 
half-empty glass of wine.

On one hand, foreign languages implementors (of GCC based compilers for niche 
languages)
did usually not make the effort to even ask their front-end to enter GCC. Maybe 
they are too shy...

But perhaps, as a community, we could possibly have (involuntarily) frightenned 
them.

And my feeling is that offering the small infrastructure to permit niche front-ends thru plugins (or something else) 
could be percieved as an invitation to join our GCC community. [In contrast to some people, I don't see plugins as a 
possibility of fragmenting the community; I see plugins as a way to attract more external people to GCC].


And the landscape did change w.r.t. RMS feelings about Objective C. My understanding is that Apple is more interested 
today (end of 2009) in LLVM than in GCC. So I won't be surprised if in a couple of years most compilers on Apple systems 
would be LLVM based (and no more GCC based). Of course, I know nothing about that, so I could be entirely wrong. (I 
suppose that most north-american GCC people know a lot more Apple than I do; I only used to have a an Apple G4 laptop 
several years ago, and it was a disappointing experience - the hardware broke after 13 months!).


BTW, I understood perhaps wrongly that Ian Taylor seems to believe that gccgo has not much future, and that most of the 
software written in Go (the Google niche language) could be compiled by something which is not GCC based.


Again, I do believe that plugins will attract new people to GCC. And I also 
believe it is a good thing.

Regards.

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

Re: gccgo: A gcc frontend for Go, a new programming language

[Ian Lance Taylor]

Basile STARYNKEVITCH  writes:

> BTW, I understood perhaps wrongly that Ian Taylor seems to believe
> that gccgo has not much future, and that most of the software written
> in Go (the Google niche language) could be compiled by something which
> is not GCC based.

I certainly hope that gccgo has a future.  I wouldn't have spent so
much time on it otherwise.  It generates better code than the other Go
compiler.

I don't personally see any particular advantage to worrying about
writing new frontends as plugins.  I think plugins have specific very
useful goals, but I don't think that new frontends are one of them.

Ian