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 Min
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:
>
>
> 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
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()":
> overlo
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
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
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
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
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 th
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-w
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.
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:
>
> Congratulat
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
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_CFLAG
> 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
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 wit
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
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 p
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 c
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
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 hand
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 exa
> but again I got into troubles
libgfortran/selected_real_kind.inc is also generated.
--
Eric Botcazou
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), param
> 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, precisio
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-
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 user
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_ed
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 com
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-establi
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 stand
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
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 b
33 matches
Mail list logo
