Re: Back End Responsibilities + RTL Generation

[Frank Riese]

On Thursday 14 December 2006 08:32, you wrote:
> The data structures for the CFG are in basic-block.h.  These data
> structures are most definitely *not* incorporated into the RTL
> structures.  The CFG is independent of the intermediate
> representations for the function instructions.  It has to be, or you
> could have the same CFG data structures for both GIMPLE and RTL.

Do you mean "or you could not have ..."?

>
> Hope this helps,
>
> Gr.
> Steven

Thanks fo your reply!

I read the parts of the source code you pointed out and it helped somewhat. 

Cheers,
Frank


pgp84o4uDkFXQ.pgp
Description: PGP signature

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Paolo Bonzini]

http://gcc.gnu.org/onlinedocs/gccint/Makefile.html
http://gcc.gnu.org/install/build.html


I read that, could you please quote the part that documents the current 
behavior.


If you wish to use non-default GCC flags when compiling the stage2 and 
stage3 compilers, set BOOT_CFLAGS on the command line when doing `make'. 
Non-default optimization flags are less well tested here than the 
default of `-g -O2', but should still work.



Let me offer a counter quote:


The counter quote is obviously wrong, thanks for the report.

Paolo

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Mike Stump]

On Dec 15, 2006, at 1:02 AM, Paolo Bonzini wrote:

The counter quote is obviously wrong, thanks for the report.


Why it is important to not have CFLAGS influence the build product?   
The standard, is for it to so influence the build product.  Why is it  
important for gcc to not follow the standard?

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Paolo Bonzini]

The counter quote is obviously wrong, thanks for the report.


Why it is important to not have CFLAGS influence the build product?  The 
standard, is for it to so influence the build product.  Why is it 
important for gcc to not follow the standard?


Because when I happened to change well-established operation modes, in 
the past, I encountered a lot of resistance, and I don't have the time 
resources to start this one more now.


Paolo

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Andrew Pinski]

On Fri, 2006-12-15 at 01:42 -0800, Mike Stump wrote:
> On Dec 15, 2006, at 1:02 AM, Paolo Bonzini wrote:
> > The counter quote is obviously wrong, thanks for the report.
> 
> Why it is important to not have CFLAGS influence the build product?   
I think because bootstrapping is actually special compared to normal
building of other programs.

> The standard, is for it to so influence the build product.  Why is it  
> important for gcc to not follow the standard?

For BOOT_CFLAGS and STAGE1_CFLAGS, if we change them to be affected by
CFLAGS, we are going to run into issues where the compiler you are
building with understand an option but the bootstrapping one does not.
An example of this is building GCC with a non GCC compiler.  So how do
we handle that case, we split out STAGE1_CFLAGS and BOOT_CFLAGS.

Thanks,
Andrew Pinski 

Help with traversing block statements in pragma handler

[Ferad Zyulkyarov]

Hi,

In a pragma handler that I put in c-pragma.c file I try to traverse
the statements of a function. Based on one of my previous postings, I
was advised to look at how this is done in cgraph_create_edges
function in cgraphunit.c file. I implement everything in the same way
as in cgraph_create_edges but unfortunately with my case it does not
work - compiler crushes. I figured out the reason for the segmentation
fault but I can not think of a work around or alternative solution

Below I give my code and explain where it crashes.

1: static void
2: handle_pragma_test(cpp_reader *ARG_UNUSED(dummy))
3: {
4: basic_block bb;
5: block_stmt_iterator bsi;
6: struct function *this_cfun = NULL;
7:
8: this_cfun = DECL_STRUCT_FUNCTION(current_function_decl);

/* Crashes on the line below (line 9, the FOR_EACH_BB_FN macro) while
trying to access this_cfun->cfg->x_entry_block_ptr->next_bb field.
When I was debugging and tyred to access this field, gdb  reports
"Cannot access memory at address ***". But the interesting point is
that the same happened when I debugged in cgraph_create_edges function
*/
9: FOR_EACH_BB_FN (bb, this_cfun)
10: for (bsi = bsi_start(bb); !bsi_end_p(bsi); bsi_next(&bsi))
11: {
12: tree stmt = bsi_stmt(bsi);
13: debug_tree(stmt);
14: /* Do something */
15: }
16: } /* End of void handle_pragma_test */

Also, when debugging, I noticed that the pragma handler is executed
before cgraph_create_edges function. Could the earlier invocation of
the pragma handler be reason for the crash when trying to get
reference (pointer) to a basic block in FOR_EACH_BB_FN macro? Probably
at this time when the pragma handler is invoked the AST is not
complete..

I would appreciate your help, any advices and comments on how to do
that (traverse the statements in function). I also attach the
c-pragma.c file and C source file "demo_pragma_usage.c" to test the
pragma handler.

Thanks,
Ferad Zyulkyarov
/* Handle #pragma, system V.4 style.  Supports #pragma weak and #pragma pack.
   Copyright (C) 1992, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
   2006 Free Software Foundation, Inc.

This file is part of GCC.

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 2, or (at your option) any later
version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
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.  */

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "rtl.h"
#include "tree.h"
#include "function.h"
#include "cpplib.h"
#include "c-pragma.h"
#include "flags.h"
#include "toplev.h"
#include "ggc.h"
#include "c-common.h"
#include "output.h"
#include "tm_p.h"
#include "vec.h"
#include "target.h"
#include "diagnostic.h"
#include "opts.h"


#include "output.h"
#include "c-tree.h"
#include "toplev.h"
#include "cgraph.h"
#include "tree-flow.h"

#define GCC_BAD(gmsgid) \
  do { warning (OPT_Wpragmas, gmsgid); return; } while (0)
#define GCC_BAD2(gmsgid, arg) \
  do { warning (OPT_Wpragmas, gmsgid, arg); return; } while (0)


typedef struct align_stack GTY(())
{
  int		   alignment;
  tree		   id;
  struct align_stack * prev;
} align_stack;

static GTY(()) struct align_stack * alignment_stack;

#ifdef HANDLE_PRAGMA_PACK
static void handle_pragma_pack (cpp_reader *);

#ifdef HANDLE_PRAGMA_PACK_PUSH_POP
/* If we have a "global" #pragma pack() in effect when the first
   #pragma pack(push,) is encountered, this stores the value of
   maximum_field_alignment in effect.  When the final pop_alignment()
   happens, we restore the value to this, not to a value of 0 for
   maximum_field_alignment.  Value is in bits.  */
static int default_alignment;
#define SET_GLOBAL_ALIGNMENT(ALIGN) (maximum_field_alignment = *(alignment_stack == NULL \
	? &default_alignment \
	: &alignment_stack->alignment) = (ALIGN))

static void push_alignment (int, tree);
static void pop_alignment (tree);

/* Push an alignment value onto the stack.  */
static void
push_alignment (int alignment, tree id)
{
  align_stack * entry;

  entry = GGC_NEW (align_stack);

  entry->alignment  = alignment;
  entry->id	= id;
  entry->prev	= alignment_stack;

  /* The current value of maximum_field_alignment is not necessarily
 0 since there may be a #pragma pack() in effect; remember it
 so that we can restore it after the final #pragma pop().  */
  if (alignment_stack == NULL)
default_alignment = maximum_field_alignment;

  alignment_stack = entry;

  maximum_field_alignment = alignment;
}

/* 

Re: Compile Farm : one year uptime, call for projects

[Thomas Schwinge]

Hello!

On Thu, Dec 14, 2006 at 09:16:07PM +0100, Laurent GUERBY wrote:
> Excepted two machines I opened to change their disk, the nine GCC
> Compile Farm bi-pentium III machines are reaching one year uptime today:

Congratulations!


> There are currently 17 users with access to the farm, new users and
> projects are as welcomed as before :).

Would me using (one of) the machines for maintaining GNU/Hurd cross-build
environments (i.e. binutils, GCC, glibc) be an admissible project?  (I'd
some few GiB of disk storage.)

If it is, then...

> 1. your ssh public key (HOME/.ssh/authorized_keys format) *in
> attachment* and not inline in the email and

Attached.

> 2. your prefered UNIX login 

`tschwinge'.


Regards,
 Thomas
ssh-rsa 
B3NzaC1yc2EBIwAAAIEAyjlpdgiBOmywOtwGtI/tZjoV8HzyBkCabLPf6eaDGuiJUxRYPoAA8za8zXtCrTkgUBHtAjYRW+uMp3Nc+UcseaqKbtneyyCIei2wc4UYUDJXWEGBmrwU54DdqoWV4SC6RmpziAoMLDzjXmPybHehRXRq0PGTHJGYTyJ7Re0eYUU=
 [EMAIL PROTECTED]
ssh-rsa 
B3NzaC1yc2EBIwAAAIEApw08AM4up4l5eS0utSY0pTH7RZekainQaDlWgClXm/vkvQmuTz4QVIKALcq51jMA6MyuObhYiUeK7FbiFiKVnTl5Fw9s0FePuPFUWE+LQFYgbvaVZKjvup0rI6PJcfq9Yw1dm9X/UuFTuZq0iR2t4jnC95EkzWLFQxlOjpGKsyU=
 [EMAIL PROTECTED]
ssh-rsa 
B3NzaC1yc2EBIwAAAIEAofOJimG8pIXs4LPTwiSVQheUbWcwI8/HHpqnQ67yW/1tyAkd0quKuefvVQExQbAJ2UxxVKk8ZhOZEQBz3jRGovSjfpJgS333kQuRQhmxxysgH01C0TegPtOHh1H7SROhHXJmff5MvIatfK173t++09qE9KJilhNPrqCNceZyig8=
 [EMAIL PROTECTED]


signature.asc
Description: Digital signature

[libgfortran, 4.2] Syntax error in array constructor

[Christian Joensson]

This is on the 4.2 branch, on

Aurora SPARC Linux release 2.90 (Aurora Corona)/TI UltraSparc IIi (Sabre) sun4u:

binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
glibc-devel-2.5-3.1.sparc64
glibc-headers-2.5-3.1.sparc
gmp-2.4.1   (local build from gcc's infrastructure)
mpfr-2.2.1  (local build from gcc's infrastructure)
kernel-2.6.18-1.2798.al3.1.sparc64
libgcc-4.1.1-30.1.sparc
libgcc-4.1.1-30.1.sparc64
libgcj-4.1.1-30.1.sparc
libgcj-4.1.1-30.1.sparc64
libgcj-devel-4.1.1-30.1.sparc
libgcj-devel-4.1.1-30.1.sparc64
libstdc++-4.1.1-30.1.sparc
libstdc++-4.1.1-30.1.sparc64
libstdc++-devel-4.1.1-30.1.sparc
libstdc++-devel-4.1.1-30.1.sparc64
make-3.81-1.1.sparc
tcl-8.4.13-3.al3.sparc

LAST_UPDATED: Fri Dec 15 08:51:23 UTC 2006 (revision 119876)

configure: ../gcc/configure   --enable-__cxa_atexit --enable-shared
--with-cpu=v7 --with-gmp=/usr/local/gmp-mpfr
--with-mpfr=/usr/local/gmp-mpfr
--enable-languages=c,c++,fortran,java,objc,obj-c++,treelang

/bin/sh ./libtool --mode=compile
/usr/local/src/branch/objdir/./gcc/gfortran
-B/usr/local/src/branch/objdir/./gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-gnu/include -isystem
/usr/local/sparc64-unknown-linux-gnu/sys-include -I . -Wall
-fno-repack-arrays -fno-underscoring  -c -o selected_int_kind.lo `test
-f 'intrinsics/selected_int_kind.f90' || echo
'../../../gcc/libgfortran/'`intrinsics/selected_int_kind.f90
/usr/local/src/branch/objdir/./gcc/gfortran
-B/usr/local/src/branch/objdir/./gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-gnu/include -isystem
/usr/local/sparc64-unknown-linux-gnu/sys-include -I . -Wall
-fno-repack-arrays -fno-underscoring -c
../../../gcc/libgfortran/intrinsics/selected_int_kind.f90  -fPIC -DPIC
-o .libs/selected_int_kind.o
../../../gcc/libgfortran/intrinsics/selected_int_kind.f90:35.5:

 do i = 1, c
   1
Error: Syntax error in array constructor at (1)
../../../gcc/libgfortran/intrinsics/selected_int_kind.f90:36.26:

   if (r <= int_infos (i) % range) then
1
Error: Syntax error in IF-expression at (1)
../../../gcc/libgfortran/intrinsics/selected_int_kind.f90:37.6:

 selected_int_kind = int_infos (i) % kind
1
Error: Unclassifiable statement at (1)
../../../gcc/libgfortran/intrinsics/selected_int_kind.f90:39.7:

   end if
 1
Error: Expecting END FUNCTION statement at (1)
../../../gcc/libgfortran/intrinsics/selected_int_kind.f90:40.5:

 end do
   1
Error: Expecting END FUNCTION statement at (1)
make[3]: *** [selected_int_kind.lo] Error 1
make[3]: Leaving directory
`/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/usr/local/src/branch/objdir'
make: *** [all] Error 2

Any ideas what is going wrong here?

--
Cheers,

/ChJ

Re: [libgfortran, 4.2] Syntax error in array constructor

[Eric Botcazou]

> Any ideas what is going wrong here?

libgfortran/selected_int_kind.inc has very likely been corrupted, which would 
mean that your Fortran compiler is non-functional.  It should contain

  integer, parameter :: c = 3
  type (real_info), parameter :: real_infos(c) = (/ &
real_info (4, precision(0.0_4), range(0.0_4)), &
real_info (8, precision(0.0_8), range(0.0_8)), &
real_info (10, precision(0.0_10), range(0.0_10)) /)

or something along these lines.

-- 
Eric Botcazou

Re: [libgfortran, 4.2] Syntax error in array constructor

[Christian Joensson]

On 12/15/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:

> Any ideas what is going wrong here?

libgfortran/selected_int_kind.inc has very likely been corrupted, which would
mean that your Fortran compiler is non-functional.  It should contain

  integer, parameter :: c = 3
  type (real_info), parameter :: real_infos(c) = (/ &
real_info (4, precision(0.0_4), range(0.0_4)), &
real_info (8, precision(0.0_8), range(0.0_8)), &
real_info (10, precision(0.0_10), range(0.0_10)) /)

or something along these lines.


sure is...

[EMAIL PROTECTED] libgfortran]$ pwd
/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libgfortran
[EMAIL PROTECTED] libgfortran]$ more selected_int_kind.inc
 integer, parameter :: c = 0
 type (int_info), parameter :: int_infos(c) = (/ &
[EMAIL PROTECTED] libgfortran]$

I removed the generated selected_int_kind.inc and tried rebuild, the
new generated looks like this now:

[EMAIL PROTECTED] objdir]$ more
sparc64-unknown-linux-gnu/libgfortran/selected_int_kind.inc
 integer, parameter :: c = 4
 type (int_info), parameter :: int_infos(c) = (/ &
   int_info (1, range(0_1)), &
   int_info (2, range(0_2)), &
   int_info (4, range(0_4)), &
   int_info (8, range(0_8)) /)

but again I got into troubles

/bin/sh ./libtool --mode=compile
/usr/local/src/branch/objdir/./gcc/gfortran
-B/usr/local/src/branch/objdir/./gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-gnu/include -isystem
/usr/local/sparc64-unknown-linux-gnu/sys-include -I . -Wall
-fno-repack-arrays -fno-underscoring  -c -o selected_real_kind.lo
`test -f 'intrinsics/selected_real_kind.f90' || echo
'../../../gcc/libgfortran/'`intrinsics/selected_real_kind.f90
/usr/local/src/branch/objdir/./gcc/gfortran
-B/usr/local/src/branch/objdir/./gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-gnu/include -isystem
/usr/local/sparc64-unknown-linux-gnu/sys-include -I . -Wall
-fno-repack-arrays -fno-underscoring -c
../../../gcc/libgfortran/intrinsics/selected_real_kind.f90  -fPIC
-DPIC -o .libs/selected_real_kind.o
../../../gcc/libgfortran/intrinsics/selected_real_kind.f90:37.21:

 selected_real_kind = 0
   1
Error: Syntax error in array constructor at (1)
../../../gcc/libgfortran/intrinsics/selected_real_kind.f90:49.28:

   if (p2 <= real_infos (i) % precision) found_p = .true.
  1
Error: Syntax error in IF-expression at (1)
../../../gcc/libgfortran/intrinsics/selected_real_kind.f90:50.28:

   if (r2 <= real_infos (i) % range) found_r = .true.
  1
Error: Syntax error in IF-expression at (1)
../../../gcc/libgfortran/intrinsics/selected_real_kind.f90:52.6:

 selected_real_kind = real_infos (i) % kind
1
Error: Unclassifiable statement at (1)
make[3]: *** [selected_real_kind.lo] Error 1
make[3]: Leaving directory
`/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/usr/local/src/branch/objdir'
make: *** [all] Error 2

So, I am pondering a complete rebuild... not trying to delete any
files and try to continue the build

--
Cheers,

/ChJ

Re: [libgfortran, 4.2] Syntax error in array constructor

[Eric Botcazou]

> but again I got into troubles

libgfortran/selected_real_kind.inc is also generated.

-- 
Eric Botcazou

Re: [infrastructure] what about gmp and mpfr on multilibbed builds?

[Christian Joensson]

On 12/14/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:

> So, my question is this: Do I need to have libgmp and libmpfr
> available as both 32 and 64 bit variants?

No if you use only one compiler (i.e. the multilibbed 32-bit compiler).


let me come back to this using a concrete example to examplify my thougts.

Now, I have an UltraSPARC system, capable of running both 32 bit and
64 bit applications.

The system is such that I configure and build the gcc compiler like this:

../gcc/configure   --enable-__cxa_atexit --enable-shared --with-cpu=v7
--with-gmp=/usr/local/gmp-mpfr --with-mpfr=/usr/local/gmp-mpfr
--enable-languages=c,c++,fortran,java,objc,obj-c++,treelang

which means I get a sparc64-unknown-linux-gnu multilibbed compiler.
That is, the compiler itself is 32 bit (due to the --with-cpu=v7 flag)
and the libraries that support multilibbed variants come in a default
32 bit variant (again, due to the --with-cpu=v7 flag) and a 64 bit
variant.

So, returning to my question here. The way I see it, should the
multilibbed enabled libraries use and gmp and/or mpfr routines, then
the gmp and mpfr libraries are needed in both 32 and 64 bit variants.
If, on the other hand, the gmp and mpfr libraries are only needed in
the compiler itself and the libraries that are not multilibbed
enabled, then gmp and mpfr are only needed as 32 bit variants.

So, again, if I have a 32 bit compiler multilibbed enabled, then only
32 bit variants of gmp and mpfr libraries requires that gmp and/or
mpfr routines are not used by the multilibbed libraries at all.
Correct?

If gcc development would eventually make use of gmp and/or mpfr in the
multilibbed libraries, that would require both 32 bit and 64 bit
variants installed. If so, I wonder if the header files support
multilibbed, 32 bit and 64 bit, install and use... in other words, I
suppose gmp and mpfr should be multilibbed :)


--
Cheers,

/ChJ

Re: Help with traversing block statements in pragma handler

[Diego Novillo]

Ferad Zyulkyarov wrote on 12/15/06 05:02:


9: FOR_EACH_BB_FN (bb, this_cfun)
10: for (bsi = bsi_start(bb); !bsi_end_p(bsi); bsi_next(&bsi))
11: {
12: tree stmt = bsi_stmt(bsi);
13: debug_tree(stmt);
14: /* Do something */
15: }
16: } /* End of void handle_pragma_test */

This is way too early in the compilation.  At this point we are not even 
in GIMPLE mode, so there will not be a flowgraph.


I recommend that you follow what happens when GCC handles structurally 
similar pragmas.  In your case, try following through #pragma omp 
parallel.  Its behaviour is very similar to what you show in your 
#pragma test.

Re: Help with traversing block statements in pragma handler

[Ferad Zyulkyarov]

Thanks Diego,

I will throw more precise look on OMP.

And something more, what is the difference between c_register_pragma
and cpp_register_deferred_pragma functions? Unfortunately, I couldn't
fined a descriptive information about these two functions.

Ferad Zyulkyarov

On 12/15/06, Diego Novillo <[EMAIL PROTECTED]> wrote:

Ferad Zyulkyarov wrote on 12/15/06 05:02:

> 9: FOR_EACH_BB_FN (bb, this_cfun)
> 10:   for (bsi = bsi_start(bb); !bsi_end_p(bsi); bsi_next(&bsi))
> 11:   {
> 12:   tree stmt = bsi_stmt(bsi);
> 13:   debug_tree(stmt);
> 14: /* Do something */
> 15:   }
> 16: } /* End of void handle_pragma_test */
>
This is way too early in the compilation.  At this point we are not even
in GIMPLE mode, so there will not be a flowgraph.

I recommend that you follow what happens when GCC handles structurally
similar pragmas.  In your case, try following through #pragma omp
parallel.  Its behaviour is very similar to what you show in your
#pragma test.

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Paul Brook]

On Friday 15 December 2006 09:02, Paolo Bonzini wrote:
> >> http://gcc.gnu.org/onlinedocs/gccint/Makefile.html
> >> http://gcc.gnu.org/install/build.html
> >
> > I read that, could you please quote the part that documents the current
> > behavior.
>
> If you wish to use non-default GCC flags when compiling the stage2 and
> stage3 compilers, set BOOT_CFLAGS on the command line when doing `make'.
> Non-default optimization flags are less well tested here than the
> default of `-g -O2', but should still work.
>
> > Let me offer a counter quote:
>
> The counter quote is obviously wrong, thanks for the report.

I think Mike's quote is only really misleading if taken out of context. The 
paragraph Paolo quoted immediately follows the text that Mike quoted.

Paul

Re: Help with traversing block statements in pragma handler

[Diego Novillo]

Ferad Zyulkyarov wrote on 12/15/06 08:46:


And something more, what is the difference between c_register_pragma
and cpp_register_deferred_pragma functions? Unfortunately, I couldn't
fined a descriptive information about these two functions.

You need to look in ../libcpp/directives.c.  Deferred pragmas are 
registered to avoid calling pragma handling while we are pre-processing.

Re: [infrastructure] what about gmp and mpfr on multilibbed builds?

[Mike Stump]

On Dec 15, 2006, at 4:11 AM, Christian Joensson wrote:

So, returning to my question here. The way I see it, should the
multilibbed enabled libraries use and gmp and/or mpfr routines, then
the gmp and mpfr libraries are needed in both 32 and 64 bit variants.


Yes.


If, on the other hand, the gmp and mpfr libraries are only needed in
the compiler itself and the libraries that are not multilibbed
enabled, then gmp and mpfr are only needed as 32 bit variants.


Yes.


So, again, if I have a 32 bit compiler multilibbed enabled, then only
32 bit variants of gmp and mpfr libraries requires that gmp and/or
mpfr routines are not used by the multilibbed libraries at all.
Correct?


Yes, exactly.


If gcc development would eventually make use of gmp and/or mpfr in the
multilibbed libraries, that would require both 32 bit and 64 bit
variants installed.


Yes.

If so, I wonder if the header files support multilibbed, 32 bit and  
64 bit, install and use... in other words, I suppose gmp and mpfr  
should be multilibbed :)


You'd get more mileage out of doing this, if you can.  For example,  
around here, we build all variations and glue them all together (ppc,  
ppc64, i386, x86_64).  This enables us to build x86_64 hosted  
compilers, i386 hosted compilers, canadian cross compilers and so on,  
no build we try would then fail because of these libraries.  There is  
a certain niceness about not having to worry about it.

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Mike Stump]

On Dec 15, 2006, at 1:56 AM, Andrew Pinski wrote:

For BOOT_CFLAGS and STAGE1_CFLAGS, if we change them to be affected by
CFLAGS, we are going to run into issues where the compiler you are
building with understand an option but the bootstrapping one does not.
An example of this is building GCC with a non GCC compiler.  So how do
we handle that case, we split out STAGE1_CFLAGS and BOOT_CFLAGS.


This proves the necessity of two different controls, namely  
BOOT_CFLAGS and STAGE1_CFLAGS.  I don't propose getting rid of those  
or removing them.  What it doesn't show is why CFLAGS can't always  
influence the build product (as long as BOOT_CFLAGS isn't set, of  
course).  A setter of CFLAGS promises to not use it when it isn't  
applicable, any time those options would not be valid for both the  
bootstrap and the stage[23] compiler, they promise not to use that  
control.


To be concrete, I'd claim, these are the right semantics:

mrs $ make
stage1 builds with -g
stage2 builds with -O2 -g
mrs $ make CFLAGS=-O2
stage1 builds with -O2
stage2 builds with -O2
mrs $ make CFLAGS=-O2 STAGE1_CFLAGS=-O0
stage1 builds with -O0
stage2 builds with -O2
mrs $ make STAGE1_CFLAGS=-O0
stage1 builds with -O0
stage2 builds with -O2 -g
mrs $ make STAGE1_CFLAGS=-O0 BOOT_CFLAGS=-O3
stage1 builds with -O0
stage2 builds with -O3
mrs $ make CFLAGS=-O0 BOOT_CFLAGS=-O3
stage1 builds with -O0
stage2 builds with -O3
mrs $ make BOOT_CFLAGS=-O3
stage1 builds with -g
stage2 builds with -O3

An argument against the proposal would explain the case that you  
specifically think is wrong, and why it is wrong.  If you need to  
test an invocation not shown above to show why it is wrong, you can  
test with:


CFLAGS := default
DEFAULT_STAGE1_CFLAGS := -g
STAGE1_CFLAGS := $(shell if [ "$(CFLAGS)" = default ]; then echo "$ 
(DEFAULT_STAGE1_CFLAGS)"; else echo "$(CFLAGS)"; fi)

DEFAULT_BOOT_CFLAGS := -O2 -g
BOOT_CFLAGS := $(shell if [ "$(CFLAGS)" = default ]; then echo "$ 
(DEFAULT_BOOT_CFLAGS)"; else echo "$(CFLAGS)"; fi)

all: stage1 stage2
stage1:
@echo stage1 builds with $(STAGE1_CFLAGS)
stage2:
@echo stage2 builds with $(BOOT_CFLAGS)

The idea is that configure gets to set up DEFAULT_STAGE1_CFLAGS and  
DEFAULT_BOOT_CFLAGS anyway it wants, if the user doesn't change his  
mind, that is what is used in those situations.  Paolo, is there any  
case that you can identify that is wrong?

Re: [infrastructure] what about gmp and mpfr on multilibbed builds?

[Eric Botcazou]

> So, again, if I have a 32 bit compiler multilibbed enabled, then only
> 32 bit variants of gmp and mpfr libraries requires that gmp and/or
> mpfr routines are not used by the multilibbed libraries at all.
> Correct?

Correct, they are only used by the compiler itself.

> If gcc development would eventually make use of gmp and/or mpfr in the
> multilibbed libraries, that would require both 32 bit and 64 bit
> variants installed. If so, I wonder if the header files support
> multilibbed, 32 bit and 64 bit, install and use... in other words, I
> suppose gmp and mpfr should be multilibbed :)

Yes, that works, at least on x86-64/Linux.

-- 
Eric Botcazou

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Andrew Pinski]

On 12/15/06, Mike Stump <[EMAIL PROTECTED]> wrote:

This proves the necessity of two different controls, namely
BOOT_CFLAGS and STAGE1_CFLAGS.  I don't propose getting rid of those
or removing them.  What it doesn't show is why CFLAGS can't always
influence the build product (as long as BOOT_CFLAGS isn't set, of
course).  A setter of CFLAGS promises to not use it when it isn't
applicable, any time those options would not be valid for both the
bootstrap and the stage[23] compiler, they promise not to use that
control.


But wait, most people don't read the documentation anyways.  So if you
have BOOT_CFLAGS be set by CFLAGS, then we end up with bug reprots
about trying to bootstrap GCC with say ICC and the options of ICC not
working at the second stage.

This is true of either way BOOT_CFLAGS is set or not, but maybe the
current way is better for people who don't read the documentation
because it means less build failures.


mrs $ make CFLAGS=-O2
stage1 builds with -O2
stage2 builds with -O2

This is not my problem with what you think BOOT_CFLAGS should be set
from CFLAGS, it causes normal build failures where some enivornent
variable was just set by the system admin by default, and yes this has
shown up in the past.

Witness the comment in http://gcc.gnu.org/install/build.html:
Note that using non-standard CFLAGS can cause bootstrap to fail if
these trigger a warning with the new compiler. For example using `-O2
-g -mcpu=i686' on i686-pc-linux-gnu will cause bootstrap failure as
-mcpu= is deprecated in 3.4.0 and above.


Thanks,
Andrew Pinski

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Marcin Dalecki]

On 2006-12-15, at 18:27, Mike Stump wrote:


On Dec 15, 2006, at 1:56 AM, Andrew Pinski wrote:
For BOOT_CFLAGS and STAGE1_CFLAGS, if we change them to be  
affected by

CFLAGS, we are going to run into issues where the compiler you are
building with understand an option but the bootstrapping one does  
not.
An example of this is building GCC with a non GCC compiler.  So  
how do

we handle that case, we split out STAGE1_CFLAGS and BOOT_CFLAGS.


This proves the necessity of two different controls, namely  
BOOT_CFLAGS and STAGE1_CFLAGS.


For consitency I would propose to use the name STAGE0_CFLAGS instead  
of BOOT_CFLAGS,

because the stages are actually enumerated in a sequence anyway.


Marcin Dalecki

Re: Compile Farm : one year uptime, call for projects

[Laurent GUERBY]

On Fri, 2006-12-15 at 11:16 +0100, Thomas Schwinge wrote:
> Hello!
> 
> On Thu, Dec 14, 2006 at 09:16:07PM +0100, Laurent GUERBY wrote:
> > Excepted two machines I opened to change their disk, the nine GCC
> > Compile Farm bi-pentium III machines are reaching one year uptime today:
> 
> Congratulations!

Thanks :)

> > There are currently 17 users with access to the farm, new users and
> > projects are as welcomed as before :).
> 
> Would me using (one of) the machines for maintaining GNU/Hurd cross-build
> environments (i.e. binutils, GCC, glibc) be an admissible project?  (I'd
> some few GiB of disk storage.)

No problem.

> If it is, then...
> 
> > 1. your ssh public key (HOME/.ssh/authorized_keys format) *in
> > attachment* and not inline in the email and
> 
> Attached.
> 
> > 2. your prefered UNIX login 
> 
> `tschwinge'.

"ssh [EMAIL PROTECTED]" should now work, do you confirm?

gcc09 is not the most powerful machine, but it is the one
with the most free local disk space, if your project needs
more than 5GB I recommand you use this one.

[EMAIL PROTECTED]:~$ df -h
FilesystemSize  Used Avail Use% Mounted on
/dev/sda1  16G   15G  215M  99% /
tmpfs 506M 0  506M   0% /dev/shm
gcc02:/home16G   11G  4.8G  69% /n/02
gcc03:/home16G  4.8G   11G  32% /n/03
gcc05:/home16G   14G  1.7G  89% /n/05
gcc06:/home16G  8.5G  6.8G  56% /n/06
gcc07:/home32G   25G  5.4G  83% /n/07
gcc08:/home32G   13G   19G  41% /n/08
/dev/sdb1  34G  8.6G   24G  28% /mnt/disk01-2
gcc09:/home32G  5.7G   25G  19% /n/09

Please update the GCC wiki CompileFarm page with a short description of
your project and the cron/machine you plan to use.

Welcome on board :).

Laurent

PS: I'll be away for 3 hours

[CFARM] Welcome to the GCC Compile Farm

* Rules for participants

1/ Request for administration should be sent to [EMAIL PROTECTED],
that includes missing packages, machines problems, suspicious
activity, etc...

2/ Everything else, proposals and request for general help should go
through gcc@gcc.gnu.org with "[CFARM]" tag in the subject. That includes
adding NFS between machines and how to do it, crontabs you've setup,
where are useful stuff you compiled (binutils, gdb, ...). Don't
forget to update the wiki: http://gcc.gnu.org/wiki/CompileFarm

3/ The machines don't have much RAM (512 MB/processor), so try to choose
one machine that hasn't already a load greater than 2. Please avoid
"-j 2" to leave room for others and easier scheduling.

4/ The machines don't have much disk (some 16GB, some 32GB), so don't
forget to clean up. Disks are not backuped, so please a copy of your
work on your own (hopefully backuped) machine. Machines see each other
/home directory through an NFS mount on /n/0X/. 

5/ Please do not put your real or GCC private keys on the machine, but
feel free to use ssh-keygen to create a specific key for easy use of
ssh within the cluster.

6/ To publish results, just scp them (in compressed form) from your
own machine and send them by email or publish them on your web site.

7/ Laurent Guerby's role is as of last resort on use of the machines,
everyone should try to get consensus on proposals on the GCC list.
The goal is to use 100% of all the CPU all the time and by doing so
improve the GCC development process.

* Misc information

* /n/07/guerby/ftp is in 775 mode and has some useful
downloaded .tar.bz2,
if you want to download something, please check this directory,
and if it's not there yet, please download to this directory.

* Current users

1001 guerby  Laurent GUERBY <[EMAIL PROTECTED]>   GCC
1002 ian Ian Lance TaylorGCC
1003 fxcoudert   François-Xavier Coudert <[EMAIL PROTECTED]> GCC
1004 ollyOlly Betts <[EMAIL PROTECTED]>  
http://www.xapian.org/  C++ library
1005 spopSebastian Pop <[EMAIL PROTECTED]>GCC
1006 manuEmmanuel Dreyfus <[EMAIL PROTECTED]>NetBSD
1007 mstein  Mike Stein <[EMAIL PROTECTED]> AVR cross & 
simulator
1008 bagnara Roberto Bagnara <[EMAIL PROTECTED]> 
http://www.cs.unipr.it/ppl/ C++ library
1009 hp  Hans-Peter Nilsson <[EMAIL PROTECTED]>  GCC
1010 jerryd  Jerry DeLisle <[EMAIL PROTECTED]> NIST Fortran 77 
testsuite / LAPACK Test Suite / Large I/O
1011 manuel  Manuel López-Ibáñez <[EMAIL PROTECTED]>  GCC Google Summer of 
Code http://gcc.gnu.org/wiki/Wcoercion
1012 geoffk  Geoffrey Keating <[EMAIL PROTECTED]>   GCC
1013 amylaar Joern RENNECKE <[EMAIL PROTECTED]>GCC
1014 david   David Nicol <[EMAIL PROTECTED] free software / 
NetBSD
1015 raskRask Ingemann Lambertsen <[EMAIL PROTECTED]>GCC
1016 pinskia Andrew Pinski <[EMAIL PROTECTED]> GCC
1017 revitaleRevital1 Eres <[EMAIL PROTECTED]> 

Re: Compile Farm : one year uptime, call for projects

[Manuel López-Ibáñez]

On 15/12/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:


* IP adresses should not be revealed for now,


Ooops! I hope you were not serious with that...

Cheers,

Manuel.

distributing g++

[Bob Rossi]

Hi,

I've compiled g++ for mingw with,

../gcc-4.1.1/configure --prefix=/home/bobbybrasko/g++/prefixdir --host=mingw32 \
  --target=mingw32 --program-prefix="" \
  --program-suffix="-4.1" --with-gcc --with-gnu-ld --with-gnu-as 
--enable-threads --disable-nls \
  --enable-languages=c,c++ --disable-win32-registry --disable-shared 
--without-x \
  --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug

Since i've used a prefix, I'm assumming gcc wants to be installed where
I told it to be. I'm wondering 2 things.

What are the standard practices with installing multiple versions of gcc
on a system. I renamed this gcc to be gcc-4.1. However, it looks like it
will still overwrite some files when I do 'make install'. Is this true?
How do people put multiple version on the same machine?

Second, say I wanted to tar up a release of gcc that i've built for
others to use. When the other user downloads and untars the file on
there filesystem in an arbitrary point, I'm assumming it won't work
because it's not in the --prefix=.. directory. Is it possible to get
around this? I would like a user to be able to untar it anywhere, and
have it work just fine. If this is possible, please advise.

Thanks,
Bob Rossi

Re: distributing g++

[Brian Dessent]

Bob Rossi wrote:

> Since i've used a prefix, I'm assumming gcc wants to be installed where
> I told it to be. I'm wondering 2 things.

It's not supposed to be that way.  The toolchain is supposed to be
relocatable for MinGW targets.  I don't know if it currently is, but
read the past threads on the topic first:




Ranjit Mathew also has a web page somewhere describing what steps and/or
patches are necessary to get a relocatable toolchain.  But I think he
does a crossed-native (canadian) build for speed reasons, so that may
complicate the procedure.

> What are the standard practices with installing multiple versions of gcc
> on a system. I renamed this gcc to be gcc-4.1. However, it looks like it
> will still overwrite some files when I do 'make install'. Is this true?
> How do people put multiple version on the same machine?

The standard way on *nix systems is by installing them to separate
prefixes, or if using the same prefix, using --program-suffix (or
variants like --program-transform-name) and possibly
--enable-version-specific-runtime-libs.

> Second, say I wanted to tar up a release of gcc that i've built for
> others to use. When the other user downloads and untars the file on
> there filesystem in an arbitrary point, I'm assumming it won't work
> because it's not in the --prefix=.. directory. Is it possible to get
> around this? I would like a user to be able to untar it anywhere, and
> have it work just fine. If this is possible, please advise.

Again, if built right the toolchain is supposed to be relocatable, that
is it locates everything with relative paths to where the binaries are
installed.  You may have to configure it with the exact prefix
"--prefix=/mingw" for this to work, I am not sure.  And also note that
configuring a --prefix of an emulated POSIX path to a native (MinGW) app
will surely fail, you should use --prefix=`cd
/home/bobbybrasko/g++/prefixdir && pwd -W` instead if that is your goal.

Brian

Re: Compile Farm : one year uptime, call for projects

[Thomas Schwinge]

Hello!

On Fri, Dec 15, 2006 at 07:51:13PM +0100, Laurent GUERBY wrote:
> On Fri, 2006-12-15 at 11:16 +0100, Thomas Schwinge wrote:
> > Would me using (one of) the machines for maintaining GNU/Hurd cross-build
> > environments (i.e. binutils, GCC, glibc) be an admissible project?  (I'd
> > some few GiB of disk storage.)
> 
> No problem.

Very nice!


> "ssh [...]" should now work, do you confirm?

It does work.


> gcc09 is not the most powerful machine, but it is the one
> with the most free local disk space, if your project needs
> more than 5GB I recommand you use this one.

Okay, that's fine.


> Please update the GCC wiki CompileFarm page with a short description of
> your project and the cron/machine you plan to use.

Will do.


> Welcome on board :).

Thanks!  :-)


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: distributing g++

[Ferad Zyulkyarov]

Hi


What are the standard practices with installing multiple versions of gcc
on a system. I renamed this gcc to be gcc-4.1. However, it looks like it
will still overwrite some files when I do 'make install'. Is this true?


As far as I know, "make install" does not overwrite any files if there
is not a previous version at the default installation path or the
directory specified by the prefix switch.


How do people put multiple version on the same machine?


In my case, I just use different installation path with the --prefixe
switch, i.e. /home/username/gcc-4.1, /home/username/gcc-4.2 ...


Second, say I wanted to tar up a release of gcc that i've built for
others to use. When the other user downloads and untars the file on
there filesystem in an arbitrary point, I'm assumming it won't work
because it's not in the --prefix=.. directory.


I think it should work because the library paths are relative to the
gcc, g++ executable.


Is it possible to get around this? I would like a user to be able to

untar it anywhere, and

have it work just fine. If this is possible, please advise.


Probably for the different target builds like linux and win it will
not work.. What I mean is if you have gcc compiled to be hosted in
linux it will not work under win and vice versa.

For more details you can refer to the configuration documentation of
gcc - http://gcc.gnu.org/install/configure.html.

Hope it was useful,
Ferad Zyulkyarov

gcc-4.1-20061215 is now available

[gccadmin]

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

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

You'll find:

gcc-4.1-20061215.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20061215.tar.bz2 C front end and core compiler

gcc-ada-4.1-20061215.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20061215.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20061215.tar.bz2  C++ front end and runtime

gcc-java-4.1-20061215.tar.bz2 Java front end and runtime

gcc-objc-4.1-20061215.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20061215.tar.bz2The GCC testsuite

Diffs from 4.1-20061208 are available in the diffs/ subdirectory.

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

Re: 4.1.2 20060928 bug?: undefined overloaded friend function for function pointer

[Dawser Stevens]

I don't know if this bug has already been fixed. I
tried to search the archives and found one that looked
vaguely similar, about function pointers and
templates, but it wasn't exactly the same.

I am using the stock compiler in Ubuntu Edgy, gcc
4.1.2 20060928. I believe it is a prerelease of 4.1.2.

The following code can be compiled with every other
compiler I have tried (including gcc 4.0 apart from
several commercial ones), but, unfortunately, gcc
4.1.2 outputs this:

overload.cpp: In function ‘int main()’:
overload.cpp:18: error: no matches converting function
‘f’ to type ‘void (*)(class A&, const int&)’
overload.cpp:4: error: candidates are: void f(A&,
const int&)
overload.cpp:5: error: void f(A&)

This is the code:

-
class A {
public:
int val(void) { return x; }
friend void f (A &a, const int &b) { a.x = b; }
friend void f (A &a) { a.x = 0; }
private:
int x;
};

typedef void (*fptr) (A &a, const int &b);

int main (void)
{
A a;
int b = 1;
fptr g;

g = f;

g (a, b);

return a.val();
}
--

I suspect the problem can create big compatibility
problems with already written math code (e.g.
matrix/vector operations), and Ubuntu is currently
shipping this version, potentially affecting many,
many users.

Thanks a lot, and sorry if it is a duplicate or known
issue. I couldn't find anything similar.

Re: 4.1.2 20060928 bug?: undefined overloaded friend function for function pointer

[Joe Buck]

On Fri, Dec 15, 2006 at 04:24:04PM -0800, Dawser Stevens wrote:
> The following code can be compiled with every other
> compiler I have tried (including gcc 4.0 apart from
> several commercial ones), but, unfortunately, gcc
> 4.1.2 outputs this:
> 
> overload.cpp: In function "int main()":
> overload.cpp:18: error: no matches converting function
> "f" to type "void (*)(class A&, const int&)"
> overload.cpp:4: error: candidates are: void f(A&,
> const int&)
> overload.cpp:5: error: void f(A&)

I think the problem is tweaked by the fact that the first declarations
of the "f" functions are in a friend statement.  If I add

class A;
void f(A &a, const int &b);
void f(A &a);

before the class, the code compiles.

> This is the code:
> 
> -
> class A {
> public:
> int val(void) { return x; }
> friend void f (A &a, const int &b) { a.x = b; }
> friend void f (A &a) { a.x = 0; }
> private:
> int x;
> };
> 
> typedef void (*fptr) (A &a, const int &b);
> 
> int main (void)
> {
> A a;
> int b = 1;
> fptr g;
> g = f;
> g (a, b);
> return a.val();
> }
> --

> I suspect the problem can create big compatibility
> problems with already written math code (e.g.
> matrix/vector operations), and Ubuntu is currently
> shipping this version, potentially affecting many,
> many users.

The standard compiler on Fedora Core 5 (4.1.1 + patches) also shows
this problem, yet they built a distro with it, so I think that it's
not a huge issue.

Re: 4.1.2 20060928 bug?: undefined overloaded friend function for function pointer

[Andrew Pinski]

> 
> On Fri, Dec 15, 2006 at 04:24:04PM -0800, Dawser Stevens wrote:
> > The following code can be compiled with every other
> > compiler I have tried (including gcc 4.0 apart from
> > several commercial ones), but, unfortunately, gcc
> > 4.1.2 outputs this:
> > 
> > overload.cpp: In function "int main()":
> > overload.cpp:18: error: no matches converting function
> > "f" to type "void (*)(class A&, const int&)"
> > overload.cpp:4: error: candidates are: void f(A&,
> > const int&)
> > overload.cpp:5: error: void f(A&)
> 
> I think the problem is tweaked by the fact that the first declarations
> of the "f" functions are in a friend statement.  If I add
> 
> class A;
> void f(A &a, const int &b);
> void f(A &a);
> 
> before the class, the code compiles.
> 
> The standard compiler on Fedora Core 5 (4.1.1 + patches) also shows
> this problem, yet they built a distro with it, so I think that it's
> not a huge issue.

This is not an issue since this is actually invalid C++ and has already been 
documented
on http://gcc.gnu.org/gcc-4.1/changes.html:
# ARM-style name-injection of friend declarations is no longer the default. For 
example:

  struct S {
friend void f();
  };

  void g() { f(); }

will not be accepted; instead a declaration of f will need to be present 
outside of the scope of S. The new -ffriend-injection option will enable the 
old behavior.


Thanks,
Andrew Pinski

Re: 4.1.2 20060928 bug?: undefined overloaded friend function for function pointer

[Joe Buck]

On Fri, Dec 15, 2006 at 07:48:29PM -0500, Andrew Pinski wrote:
> This is not an issue since this is actually invalid C++ and has already been 
> documented
> on http://gcc.gnu.org/gcc-4.1/changes.html:
> # ARM-style name-injection of friend declarations is no longer the default. 
> For example:
> 
>   struct S {
> friend void f();
>   };
> 
>   void g() { f(); }

> will not be accepted; instead a declaration of f will need to be present
> outside of the scope of S. The new -ffriend-injection option will enable
> the old behavior.

Yes, I'd vaguely recalled this, which is why I thought of adding
real declarations of f().  But I still think that there is a bug here:
the error message produced is nonsense.

It looks like

q.C: In function int main():
q.C:18: error: no matches converting function f to type void 
(*)(class A&, const int&)
q.C:4: error: candidates are: void f(A&, const int&)
q.C:5: error: void f(A&)

However, this is false: neither declaration of f is a candidate, because
name-injection of friends is not allowed.  If they were candidates, the
first one would be an exact match and would be accepted.

Re: distributing g++

[Bob Rossi]

On Fri, Dec 15, 2006 at 12:35:23PM -0800, Brian Dessent wrote:
> Bob Rossi wrote:
> 
> > Since i've used a prefix, I'm assumming gcc wants to be installed where
> > I told it to be. I'm wondering 2 things.
> 
> It's not supposed to be that way.  The toolchain is supposed to be
> relocatable for MinGW targets.  I don't know if it currently is, but
> read the past threads on the topic first:
> 
> 
> 
> 
> Ranjit Mathew also has a web page somewhere describing what steps and/or
> patches are necessary to get a relocatable toolchain.  But I think he
> does a crossed-native (canadian) build for speed reasons, so that may
> complicate the procedure.

OK, I followed this tutorial I believe.
http://rmathew.com/articles/gcj/bldgcj.html
the section "Building a Native Compiler".

I ran this,

#!/bin/sh

tar -zxvf gcc-core-4.1.1.tar.gz
tar -zxvf gcc-g++-4.1.1.tar.gz

mkdir builddir
cd builddir
../gcc-4.1.1/configure --prefix=/mingw --host=mingw32 \
  --target=mingw32 --program-prefix="" \
  --program-suffix="-4.1" --with-gcc --with-gnu-ld --with-gnu-as 
--enable-threads --disable-nls \
  --enable-languages=c,c++ --disable-win32-registry --disable-shared 
--without-x \
  --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug \
  2>&1 | tee configure-out.txt
make bootstrap 2>&1 | tee make-out.txt
make DESTDIR=/home/bobbybrasko/g++-4.1-relocatable install

$ ls /home/bobbybrasko/g++-4.1-relocatable  

mingw   


$ ls /home/bobbybrasko/g++-4.1-relocatable/mingw

bin  include  info  lib  libexec  man  share


Am I doing the correct thing here? Pretend this isn't mingw even, would
this be the correct way to do this for native linux?

Now, How would I tar this up so that it could be relocatable? 

Thanks,
Bob Rossi