--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-08-06 07:02
---
Known problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-08-06 07:22 ---
(In reply to comment #1)
> The scheduler should not know anything about if a register is likely to spill
> or not, that is the job of the RA.
CLASS_LIKELY_SPIULLED is special because there is simply no way for reloa
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-08-06 07:24 ---
(In reply to comment #5)
> Also one comment about your patch for soft-fp:
> + /* Wrap the sequence in REG_LIBCALL / REG_RETVAL notes so that loop
> + invariant code motion can move it. */
>
> The tree level lo
--- Comment #8 from skunk at iskunk dot org 2006-08-06 07:26 ---
(In reply to comment #7)
> You cannot expect that to work. You're trying to bootstrap a 32-bit compiler
> (sparc-sun-solaris2.8) with a 64-bit compiler (cc -xarch=v9). Unsupported.
No, I'm trying to build a 64-bit GCC us
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-06 07:34
---
> No, I'm trying to build a 64-bit GCC using cc in 64-bit mode (as per CFLAGS)
> on
> a 64-bit system. Nothing fancy here.
Sure, but you're not using the correct procedure. Use the first I posted.
> You don't
--- Comment #10 from schwab at suse dot de 2006-08-06 08:01 ---
(In reply to comment #8)
> You don't pass compiler flags in CC. That's what CFLAGS is for.
Passing -xarch=v9 to the compiler makes it a different compiler in essence, one
that creates object files that are incompatible with
--- Comment #11 from skunk at iskunk dot org 2006-08-06 08:09 ---
(In reply to comment #9)
> You do for GCC. Tweaking CFLAGS for a bootstrap is a recipe for disaster.
How is it any worse than having those flags in CC? CC and CFLAGS are always
supposed to be used together anyway---the o
--- Comment #12 from skunk at iskunk dot org 2006-08-06 08:32 ---
(In reply to comment #10)
> Passing -xarch=v9 to the compiler makes it a different compiler in essence,
> one
> that creates object files that are incompatible with the output of the default
> compiler. It also changes t
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-08-06 08:46
---
> How is it any worse than having those flags in CC? CC and CFLAGS are always
> supposed to be used together anyway---the only difference with what you're
> describing is that this follows the standard variable c
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-08-06 08:48
---
> That's a fairly slippery slope. Does -KPIC/-fPIC/etc. make cc a different
> compiler? -g/-O? -g/-pg? (Yes, the linker might be able to handle those
> combinations, but you may end up with a Frankenbinary that f
--- Comment #15 from skunk at iskunk dot org 2006-08-06 09:44 ---
(In reply to comment #13)
> It's worse because tweaking CFLAGS makes you think you can do whatever you
> want with it. You cannot, as explained by Andreas.
Per Andreas, the "cannot" part stems directly from using CC alon
with the attached testcase, during linking you get:
test2.o:(.data+0x0): multiple definition of `_ZN3BadIT_E2_yE'
test1.o:(.data+0x0): first defined here
this comes from a template class:
template
class Bad {
static const int _y;
};
template const int Bad::_y = 1023;
although this seem
--- Comment #1 from tausq at debian dot org 2006-08-06 10:07 ---
Created an attachment (id=12026)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12026&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-08-06 10:59
---
> (**None** of what you're saying is currently in the docs, so far as I can
> see.)
Take a look at http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
> If users ignoring docs is a problem, then do as t
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-08-06 11:02
---
> CC+CFLAGS and the --host parameter of configure must always be in keeping.
--build actually.
> For a native compilation (hence a bootstrap), --target must additionally be.
As well as --host.
--
http://g
--- Comment #4 from bonzini at gnu dot org 2006-08-06 12:06 ---
Subject: Bug 26827
Author: bonzini
Date: Sun Aug 6 12:06:31 2006
New Revision: 115969
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115969
Log:
2006-08-06 Paolo Bonzini <[EMAIL PROTECTED]>
PR target/268
--- Comment #2 from tbm at gcc dot gnu dot org 2006-08-06 13:41 ---
This has been fixed already, both in GCC's SVN and in Debian's gcc-4.1 package.
The reason you see it on HPPA is that recent version of gcc-4.1 in Debian don't
build. This bug was fixed in -9 but hppa still has -8. Ca
--- Comment #16 from tbm at gcc dot gnu dot org 2006-08-06 13:41 ---
*** Bug 28620 has been marked as a duplicate of this bug. ***
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from tbm at gcc dot gnu dot org 2006-08-06 14:23 ---
(In reply to comment #4)
> Subject: Bug 26827
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115969
> Log:
> 2006-08-06 Paolo Bonzini <[EMAIL PROTECTED]>
>
> PR target/26827
> * config/i386/i3
--- Comment #11 from paolo at gcc dot gnu dot org 2006-08-06 14:45 ---
Subject: Bug 16611
Author: paolo
Date: Sun Aug 6 14:45:04 2006
New Revision: 115972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115972
Log:
2006-08-06 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #12 from pcarlini at suse dot de 2006-08-06 14:47 ---
Now I get:
<_Z1fRKSt6vectorIbSaIbEEj>:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 8b 45 08mov0x8(%ebp),%eax
6: 8b 4d 0c
--- Comment #36 from whaley at cs dot utsa dot edu 2006-08-06 15:03 ---
Paola,
Thanks for working on this. We are making progres, but I have some mixed
results. I timed the assemblies you provided directly. I added a target
"asgexe" that builds the same benchmark, assuming assembly s
After build a new version of procps using the "-Os" flag for gcc, all its
(procps) software (ps, top, etc) were failing due to a segmentation fault. I
couldn't find a report about that at Bugzilla, but I did find one at
"http://www.netdomination.org/~stkn/index.php?/archives/24-Anatomy-of-a-segfaul
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |target
Summary|SEGSEGV at set_fast_math () |[4.1/4.2 Regre
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-06 17:19 ---
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01179.html
Caused by the patch at:
http://gcc.gnu.org/ml/gcc/2005-08/msg00281.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed
We get the following ICE on m68k with gcc 4.1. I checked today's SVN and 4.1
fails while 4.2 works.
(sid)34:[EMAIL PROTECTED]: ~] /usr/local/bin/m68k-linux-gnu-gcc-4.1.2 -c -O
kdelibs-slaveinterface.cpp
kdelibs-slaveinterface.cpp: In function âQDataStream&
operator<<(QDataStream&, const KIO::UD
--- Comment #1 from tbm at cyrius dot com 2006-08-06 17:50 ---
Created an attachment (id=12027)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12027&action=view)
test case
Testcase from application "kdelibs".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28622
We get the following ICE on alpha with 4.1 and 4.2. gcc 4.0 works.
[EMAIL PROTECTED]:~$ gcc-4.1 -c -O kdegraphics-gstring.cpp
kdegraphics-gstring.cpp: In member function 'GP
GStringRep::vformat(va_list) const':
kdegraphics-gstring.cpp:57: error: unrecognizable insn:
(insn 15 10 16 0 (set (reg:DI
--- Comment #2 from freyther at inf dot fu-berlin dot de 2006-08-06 17:54
---
Created an attachment (id=12028)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12028&action=view)
Same as 12022 but for gcc4.1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28615
--- Comment #1 from tbm at cyrius dot com 2006-08-06 17:55 ---
Created an attachment (id=12029)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12029&action=view)
test case
Testcase from application "kdegraphics".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623
--- Comment #2 from hjl at lucon dot org 2006-08-06 18:29 ---
The main problem is bug 27537. That is -Os aligns stack at 4 bytes and the
other
part of i386 backend assumes stack aliged at 16byte. We can word around this by
1. Don't include crtfastmath.o for -m32.
2. Make crtfastmath.o d
--- Comment #3 from patchapp at dberlin dot org 2006-08-06 18:35 ---
Subject: Bug number PR28425
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00152.html
--
http://gcc.gnu.org/bugzilla/sh
I got a segfault with a recent version of gcc 4.2 on x86_64. It has gone away
recently but after investigating when it was introduced and fixed I got the
impression that this is a latent problem.
With the attached testcase, I can reproduce this segfault starting with r115200
until r115711. As fa
set_ld_library_path_env_vars:
ld_library_path=.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-
hpux11.11/./libjava/.libs
Executing on host:
/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/.
./libtool --silent --tag=GCJ --mode=link /mnt/gnu/gcc/objdir/gcc/gcj
-B/mnt/gnu/
gcc/objdir/hppa2.0w-hp-hpux11.
--- Comment #1 from tbm at cyrius dot com 2006-08-06 18:38 ---
Created an attachment (id=12030)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12030&action=view)
test case
Preprocessed source from application "fityk".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28624
--- Comment #2 from tbm at cyrius dot com 2006-08-06 18:39 ---
Program received signal SIGSEGV, Segmentation fault.
remove_phi_node (phi=0x2ace1982f900, prev=0x0) at gcc/tree-phinodes.c:458
458loc = &PHI_CHAIN (*loc))
(gdb) where
#0 remove_phi_node (phi=0x2ace1982f900, p
byte compile: /mnt/gnu/gcc/objdir/gcc/gcj
-B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux
11.11/libjava/ -B/mnt/gnu/gcc/objdir/gcc/ --encoding=UTF-8 -C
-I/mnt/gnu/gcc/obj
dir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../libgcj-4.2.0.jar -g
/mnt/gnu/gcc/
gcc/libjava/testsuite/libjava.lang/Thread_Join.java -d
/
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-08-06 20:15
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assign
This change caused a new testsuite regression on windows32 targets
2006-08-01 Volker Reichelt <[EMAIL PROTECTED]>
PR c++/28250
PR c++/28257
PR c++/28259
PR c++/28267
* toplev.c (compile_file): Return early on errorcount or sorrycount.
* cgraphuni
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #1 from tromey at gcc dot gnu dot org 2006-08-06 21:35 ---
I'm testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #2 from tromey at gcc dot gnu dot org 2006-08-06 21:52 ---
Subject: Bug 28576
Author: tromey
Date: Sun Aug 6 21:52:04 2006
New Revision: 115976
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115976
Log:
PR libgcj/28576:
* gnu/java/net/natPlainDatagra
--- Comment #3 from tromey at gcc dot gnu dot org 2006-08-06 21:52 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #1 from bangerth at dealii dot org 2006-08-06 22:12 ---
For some reason, this also passes icc. Interestingly, it isn't even the
case that offsetof manages to look through operator[] -- removing the
body of operator[] doesn't affect the result.
W.
--
bangerth at dealii do
--- Comment #5 from bangerth at dealii dot org 2006-08-06 22:16 ---
Confirmed. I'm sure this is a duplicate of some other PR, but I don't
know which one right now...
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #1 from bangerth at dealii dot org 2006-08-06 22:19 ---
Confirmed. To make things worse, the diagnostic is really longish
right now as well:
g/x> c++ -c x.cc
x.cc:10: error: reference to 'B' is ambiguous
x.cc:4: error: candidates are: struct A::B
x.cc:4: error:
--- Comment #1 from tromey at gcc dot gnu dot org 2006-08-06 22:23 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #2 from tromey at gcc dot gnu dot org 2006-08-06 22:43 ---
Subject: Bug 28491
Author: tromey
Date: Sun Aug 6 22:43:05 2006
New Revision: 115977
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115977
Log:
PR libgcj/28491:
* configure, include/config.h.
--- Comment #2 from tromey at gcc dot gnu dot org 2006-08-06 22:43 ---
Shouldn't we just pull in the fix from the gcj-eclipse branch?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2006-08-06 22:44 ---
Fix checked in on trunk.
This could be backported by someone if need be.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2006-08-06
22:47 ---
The current patch doesn't seem to work any more. I get a compile error on the
current gcc trunk svn
pull...
../../gcc-4.2-20060806/gcc/fortran/parse.c: In function 'parse_derived':
../../g
--- Comment #3 from mark at gcc dot gnu dot org 2006-08-06 23:24 ---
This seems to be partially fixed by:
2006-08-03 Sven de Marothy <[EMAIL PROTECTED]>
* gnu/java/awt/peer/gtk/ComponentGraphics.java
(grab, nativeGrab): New methods.
* include/gnu_java_awt_peer
--- Comment #2 from danglin at gcc dot gnu dot org 2006-08-06 23:42 ---
Subject: Bug 27033
Author: danglin
Date: Sun Aug 6 23:41:57 2006
New Revision: 115978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115978
Log:
PR testsuite/27033
* g++.dg/eh/spbp.C: Skip o
--- Comment #3 from danglin at gcc dot gnu dot org 2006-08-06 23:44 ---
Skipped on trunk.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #7 from danglin at gcc dot gnu dot org 2006-08-06 23:56 ---
Subject: Bug 27611
Author: danglin
Date: Sun Aug 6 23:56:24 2006
New Revision: 115979
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115979
Log:
PR testsuite/27611
* g++.dg/other/unused1.C:
--- Comment #8 from danglin at gcc dot gnu dot org 2006-08-06 23:58 ---
Skipped on 32-bit PA hpux.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from danglin at gcc dot gnu dot org 2006-08-07 00:04 ---
Subject: Bug 28603
Author: danglin
Date: Mon Aug 7 00:04:06 2006
New Revision: 115980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115980
Log:
PR libfortran/28603
* gfortran.dg/direct_io_6
--- Comment #4 from danglin at gcc dot gnu dot org 2006-08-07 00:05 ---
Skipped.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #18 from skunk at iskunk dot org 2006-08-07 04:32 ---
(In reply to comment #16)
> > (**None** of what you're saying is currently in the docs, so far as I can
> > see.)
>
> Take a look at http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
Okay, so the sparc64 and CC
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-08-07 05:32
---
> Now, if the failure was in linking code built with xgcc against the original
> [cc-built] libiberty, then that's a more meaningful issue---because CFLAGS
> doesn't apply there.
Right, this would have failed he
--- Comment #20 from skunk at iskunk dot org 2006-08-07 05:51 ---
(In reply to comment #19)
> Everything is always doable if resources permit. Tweaking CFLAGS is simply
> not generically supported and I don't think we have plan to that effect.
Okay. No generic flag-tweaking support is
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-08-07 06:11
---
> Okay. No generic flag-tweaking support is perfectly fine. Can we either...
>
> (1) Straighten things out so that if you do have to pass a flag(s) to the
> compiler, it is passed in through CFLAGS---thus respec
--- Comment #37 from bonzini at gnu dot org 2006-08-07 06:19 ---
I don't see how the last fmul[sl] can be removed without increasing code size.
The only way to fix it would be to change the machine description to say that
"this processor does not like FP operations with a memory operand
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-08-07 06:23
---
> This isn't just about sparc64, you know. The whole reason why this came up in
> the first place is because I'm building GCC in a custom autobuild framework,
> across a number of architectures. For every other a
--- Comment #23 from skunk at iskunk dot org 2006-08-07 06:43 ---
(In reply to comment #21)
> I'd only add that the upcoming GCC 4.2 release will feature a new bootstrap
> procedure (aka toplevel bootstrap) that could solve the issue.
Very interesting. I'll have a look at it. If this re
--- Comment #1 from bonzini at gnu dot org 2006-08-07 06:55 ---
but it makes code undebuggable, doesn't it (because the GCC code keeps the
return address in place)
--
bonzini at gnu dot org changed:
What|Removed |Added
-
67 matches
Mail list logo
