One appropriate default for --with-build-tools could be the same as
the defaults for --program-transform-name. A default native build
would use 'as', a default cross build would use '$target-as'. Most
people using --program-prefix would probably also pass the same value
to --with-build-tools.
Yes, this seems to meet the needs I expressed. Thanks, Jan
Paolo Bonzini [EMAIL PROTECTED] 23.12.05 10:10:01
One appropriate default for --with-build-tools could be the same as
the defaults for --program-transform-name. A default native build
would use 'as', a default cross build would use
On Thu, Dec 22, 2005 at 11:39:20AM -0500, Daniel Jacobowitz wrote:
On Thu, Dec 22, 2005 at 05:34:14PM +0100, Gunther Nikl wrote:
Hello!
The new scheme to select target tools breaks building GCC for me. Maybe I
have an unusal setup. The problem in my case is that configure now chooses
On Fri, Dec 23, 2005 at 10:10:01AM +0100, Paolo Bonzini wrote:
2) look into the --with-build-tools path, for both a Canadian cross and
a native build. This defaults to $exec_prefix/$target/bin, so the
default build tools (used in autoconf tests and by the being-built GCC)
would be, if
Gunther Nikl wrote:
On Fri, Dec 23, 2005 at 10:10:01AM +0100, Paolo Bonzini wrote:
2) look into the --with-build-tools path, for both a Canadian cross and
a native build. This defaults to $exec_prefix/$target/bin, so the
default build tools (used in autoconf tests and by the being-built
Hi all,
i'm going into holiday and i wish you all of the gcc-team a happy christmas
and thanks for all your work, even though it is still to early for christmas
wishes :).
cu,
Ronny Peine
On Fri, Dec 23, 2005 at 01:33:30PM +0100, Paolo Bonzini wrote:
Gunther Nikl wrote:
If the above isn't restricted to canadian cross, it looks good. This
should apply for a normal cross build as well: (build == host) != target
Yes. My distinction between native and cross, was more referring
On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote:
On Thu, Dec 22, 2005 at 11:39:20AM -0500, Daniel Jacobowitz wrote:
On Thu, Dec 22, 2005 at 05:34:14PM +0100, Gunther Nikl wrote:
Hello!
The new scheme to select target tools breaks building GCC for me. Maybe I
have an
On Fri, Dec 23, 2005 at 08:36:21AM -0500, Daniel Jacobowitz wrote:
On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote:
Sorry for being vague, its a cross-compiler (build == host). The build
errors out for libgcc.a since gcc/xgcc uses the wrong assembler. The
last successful build
Hi,
When bootstrapping rev. 109012 on ia64-linux (checked out around 9am GMT
today), I get
make[3]: Entering directory `/mnt/sda5/bonzo/obj-trunk/stage2-libdecnumber'
source='../../trunk/libdecnumber/decNumber.c' object='decNumber.o'
libtool=no /home/bonzo/local/obj-trunk/./prev-gcc/xgcc
Gunther Nikl wrote:
On Fri, Dec 23, 2005 at 08:36:21AM -0500, Daniel Jacobowitz wrote:
On Fri, Dec 23, 2005 at 01:19:14PM +0100, Gunther Nikl wrote:
Sorry for being vague, its a cross-compiler (build == host). The build
errors out for libgcc.a since gcc/xgcc uses the wrong assembler. The
On Fri, Dec 23, 2005 at 03:50:50PM +0100, Paolo Bonzini wrote:
Wait wait wait wait wait. This is a cross compiler. Are we mistakenly
running $prefix/bin/$target-as, which is a bad version, or are we
really running $prefix/bin/as, a program named as? If we're doing
that, let's fix that
I am doing this in my own start-up code.
If you're not using my crt0.s then you REALLY need to at least look at
it and see where/how I copy all the ROM data into RAM so that you can
access it.
However, this is not the expected behavior, especially when using
hardware. My .rodata should be in
The SPARC psABI defines that a caller must allocate the space for a
structure returned from the callee. If the callee sees the size marker
in the allocation matches the size of the return then it fills the slot.
If the size matches we return, if it doesn't match we return anyway but
add a fixed
Some more info, the reason hpux only showed one XPASS in 3.4 seems to
be that the regexp isn't correct to match the assembler syntax.
Patches were installed on mainline but not in 3.4 for mmix and hpux:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02513.html
On Fri, Dec 23, 2005 at 02:27:41PM -0500, Kaveh R. Ghazi wrote:
Some more info, the reason hpux only showed one XPASS in 3.4 seems to
be that the regexp isn't correct to match the assembler syntax.
Patches were installed on mainline but not in 3.4 for mmix and hpux:
On Fri, Dec 23, 2005 at 11:33:20AM -0800, Janis Johnson wrote:
PS: I'm going to try applying the patch to 3.4 and see if it fixes
tinfo1.C.
Meanwhile I'm running a regression hunt for the fix on mainline, which
is currently looking between 2005-07-29 and 2005-07-30. Perhaps that's
not
Snapshot gcc-4.1-20051223 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051223/
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
On Fri, Dec 23, 2005 at 11:33:20AM -0800, Janis Johnson wrote:
PS: I'm going to try applying the patch to 3.4 and see if it fixes
tinfo1.C.
Meanwhile I'm running a regression hunt for the fix on mainline,
which is currently looking between 2005-07-29 and 2005-07-30.
Perhaps
--- Comment #9 from chat95 at mac dot com 2005-12-23 08:07 ---
Hello, Pawel Sikora!
I tried with (2005/12/23)
svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 109008
and this problem has been solved!!
thank you very much!!
--
--- Comment #10 from chat95 at mac dot com 2005-12-23 08:07 ---
.
--
chat95 at mac dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from chat95 at mac dot com 2005-12-23 08:10 ---
hi all,
i tried with gmake (GNU Make 3.81beta4) as Arno told,
build and installs file for me.
uname -a
FreeBSD debussy.private.org 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Mon Nov 21
09:36:37 JST 2005 [EMAIL
--- Comment #5 from chat95 at mac dot com 2005-12-23 08:13 ---
sorry
file for me - fine for me
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
$ uname -a
Linux hertz 2.6.7-gentoo-r14 #8 SMP Mon Sep 6 16:08:44 BST 2004 x86_64 AMD
Opteron(tm) Processor 844 AuthenticAMD GNU/Linux
gcc-4.2.0 svn revision 108950.
$ cd build_hertz
$ rm -rf *
$ ../trunk/gcc/configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu
--- Comment #1 from eesrjhc at bath dot ac dot uk 2005-12-23 08:55 ---
Argh -- how embarassing. I'd been looking at it for ages and never seen my
error. I should have used ../trunk/configure not ../trunk/gcc/configure
etc.
Sorry for the noise.
--
eesrjhc at bath dot ac dot uk
--- Comment #9 from jakub at gcc dot gnu dot org 2005-12-23 09:43 ---
Subject: Bug 25005
Author: jakub
Date: Fri Dec 23 09:43:36 2005
New Revision: 109013
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109013
Log:
PR target/25005
* regrename.c
--- Comment #10 from jakub at gcc dot gnu dot org 2005-12-23 09:44 ---
Subject: Bug 25005
Author: jakub
Date: Fri Dec 23 09:44:41 2005
New Revision: 109014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109014
Log:
PR target/25005
* regrename.c
--- Comment #11 from jakub at gcc dot gnu dot org 2005-12-23 09:49 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
$ cat driver.cxx
template typename X
struct Ref
{
};
namespace Bits
{
template typename X
X
x ();
}
template typename X, typename Y
typeof (Bits::xX () + Bits::xY ())
operator+ (RefX const x, RefY const y)
{
return X (0) + Y (0);
}
int
main ()
{
Refint ra;
Refint rb;
int j = ra
We should probably issue a warning or error here, or
else blank out the rest of the line (g77 and ifort do so).
This is a corner case of an extension, so I don't think this
merits anything more than enhancement.
$ cat dollar.f
program main
character*20 line
line =
Hi all. g++ 3.4.4 seems to accept calling a destructor ~T() on a char * pointer
if you're inside a template in certain cases. Obviously not very serious in the
grand scheme of things! Apologies if this has been fixed - I couldn't find it
in the bug list, though.
--- START EXAMPLE ---
class Foo
I just tried to compile the gcc-4.2 snapshot 20051217 with the Intel C
compiler. It said
1.
../../src/gcc-4.2-20051217/gcc/builtins.c(1155): remark #593: variable
apply_args_reg_offset was
set but never used
The source code is
static int apply_args_reg_offset[FIRST_PSEUDO_REGISTER];
I have
--- Comment #31 from dir at lanl dot gov 2005-12-23 15:14 ---
Hi Jerry,
Would you go ahead and commit this ? A test case something like that in
Comment #9 shows the problem before and the fix after or may be you have a
better one from NIST. The change suggest in comment #14 fixes
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:52 ---
*** This bug has been marked as a duplicate of 11078 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from pinskia at gcc dot gnu dot org 2005-12-23 15:52
---
*** Bug 25544 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11078
If you compile by non GCC compiler change:
#define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
to:
#define INTTYPE_MAXIMUM(t) ((t) (~ ((t) 0 - INTTYPE_MINIMUM (t
gcc-4.1-20051008
--
Sent from the gcc - bugs forum at Nabble.com:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:57 ---
Confirmed, only a 3.4 regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Testcase:
class Foo {};
struct Bing
{
char *GetChar();
};
templatetypename T struct Bar
{
void Wibble()
{
bing.GetChar()-~T(); // How can this be legal if T isn't char?
}
Bing bing;
};
-
If we change the return type of GetChar() to Foo * (from char*), we get an
error:
t.cc: In
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-23 16:03 ---
I should note that we should reject this earlier, so I filed PR 25548.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25546
After the end of file is read, the file data is corrupted -
[dranta:~/tests/gfortran-D] dir% gfortran -o write17 write17.f
[dranta:~/tests/gfortran-D] dir% write17
538976288
Abort
[dranta:~/tests/gfortran-D] dir% cat write17.f
integer data
data=-1
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-12-23 17:58
---
(In reply to comment #2)
So it seems the problem was introduced within the last 24 hours.
To be a bit more precise: works with revision 108902, ICE:s with revision
108943.
--
--- Comment #13 from uweigand at gcc dot gnu dot org 2005-12-23 18:38
---
Subject: Bug 21041
Author: uweigand
Date: Fri Dec 23 18:38:43 2005
New Revision: 109019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109019
Log:
PR rtl-optimization/21041
* reload.c
--- Comment #14 from uweigand at gcc dot gnu dot org 2005-12-23 18:44
---
Subject: Bug 21041
Author: uweigand
Date: Fri Dec 23 18:44:07 2005
New Revision: 109020
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109020
Log:
PR rtl-optimization/21041
* reload.c
--- Comment #15 from uweigand at gcc dot gnu dot org 2005-12-23 18:45
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
gcov incorrectly shows that a lone return statement inside a block
has executed when in fact it has not
Environment:
System: Linux mercury.acucorp.com 2.4.18-27.8.0smp #1 SMP Fri Mar 14 07:13:13
EST 2003 i686 athlon i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
--- Comment #9 from pcarlini at suse dot de 2005-12-23 20:12 ---
FWIW, on x86-linux at least, we are making progress on the compiler side.
With 4.0.2 I get (-O2):
_Z1fRKSt6vectorIbSaIbEEj:
0: 55 push %ebp
1: 89 e5 mov
--- Comment #32 from jvdelisle at gcc dot gnu dot org 2005-12-23 20:21
---
Yes, I will work this up with a proper test case and submit for approval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-23 20:53 ---
Confirmed, only a 4.0 regression. Works in 4.1.0 and 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2005-12-23 20:54 ---
I'm working on a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2005-12-23 20:55 ---
My PR 19132 fix should fix this as well.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pcarlini at suse dot de 2005-12-23 21:13 ---
Well, I'm not sure that, besides code size, 4_1 is doing better than 4.0.2, but
both are certainly better than 3.4.x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
The following invalid code snippet is not rejected:
struct A {};
struct B
{
friend A::~B();
};
The problem appeared in gcc 4.0.0.
--
Summary: [4.0/4.1/4.2 regression] Invalid destructor name
accepted in friend
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-23 23:16
---
Subject: Bug 24671
Author: mmitchel
Date: Fri Dec 23 23:16:12 2005
New Revision: 109022
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109022
Log:
PR c++/24671
* pt.c (instantiate_template):
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-23 23:17
---
Subject: Bug 24671
Author: mmitchel
Date: Fri Dec 23 23:17:12 2005
New Revision: 109023
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109023
Log:
PR c++/24671
* pt.c (instantiate_template):
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-23 23:18
---
Subject: Bug 24671
Author: mmitchel
Date: Fri Dec 23 23:18:06 2005
New Revision: 109024
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109024
Log:
PR c++/24671
* pt.c (instantiate_template):
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-23 23:24
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from geoffk at geoffk dot org 2005-12-23 23:33 ---
Subject: Re: New: zero-initialized constants are place in .bss
drepper at redhat dot com [EMAIL PROTECTED] writes:
const struct foo f;
The compiler will mark the variable f in .bss instead of, as the const
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-12-23 23:40
---
I've finally figured out a tractable solution to this problem: just treat these
as dynamic initializations. That will be slightly less efficient than what the
C front end does, and result in a different
I don't know what this optimization is called but we miss the removal of the
load of a global variable:
int t;
int g(int);
int f(int tt)
{
if (tt)
t = 2;
else
t = 3;
return g(t);
}
I should note I found this while looking at LAPACK.
--
Summary: Missed removal of load
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-24 01:51 ---
I should mention this shows up semi a lot in fortran code as what happens is
that t is not really a global variable but instead a local variable which is
passed to another function.
--
When compiling the supplied test case with `gcc -c -O2 -ftracer test.c` with
gcc-4.0.3 the following error occurs:
test.c: In function mpfr_pow_ui:
test.c:18: error: unrecognizable insn:
(insn 96 44 46 6 (set (reg:CCZ 17 flags)
(compare:CCZ (and:DI (reg/v:DI 66 [ n ])
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-24 04:38 ---
Better testcase which shows it also on the 3.4 branch:
unsigned int __gmpfr_flags;
int
f (unsigned long int n)
{
int prephitmp3;
int i;
long unsigned int m;
if (n == 0)
prephitmp3 = -2;
else
{
m = n;
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-24 07:54 ---
ICC does not even do this optimization.
I should note that Fortran code has something like this, except you don't need
to know about the function that is being called, just the variable and if it
has TARGET on it
65 matches
Mail list logo
