--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 06:02 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-13 06:05 ---
This is nothing we can really do for very very old versions of GCC really, they
are no longer supported.
By the way when building 3.3.4, you should use make bootstrap and not just
make, it will most likely pass at
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-09-13 06:19 ---
For the record, I'm strongly in favor of variadic templates. Key parts of TR1
(tuple, functional) necessitate some kind of compiler support in order to have
full implementations: the current limits on tuple size are
--- Comment #27 from WISD00M at GMX dot NET 2006-09-13 06:19 ---
(In reply to comment #26)
# uname -a
as previously mentioned (comment #9), it's: Linux syssiphus 2.6.17.4 #1 SMP
PREEMPT Mon Sep 11 14:42:28 CEST 2006 i686 unknown
# cat /proc/cpuinfo
processor : 0
vendor_id
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 06:21 ---
Confirmed, this is a regression as partition_stack_vars is new in 4.0.x.
I am thinking about either creating a meta-bug or a keyword about all the
problems with unstable sorts/hashing with memory addresses problems.
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-13 06:23 ---
(In reply to comment #7)
Is there a good reason why gcc can't officially support being built without a
libc by either figuring out that there's no libc itself or by offering some
kind of --i-do-not-have-a-libc
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-09-13 06:26 ---
Janis, this is how to set timeout on the make check command line:
time make check RUNTESTFLAGS=-v -v -v -v --tool_opts timeout=300
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29028
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 06:29 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rsandifo at gcc dot gnu dot org 2006-09-13 06:31
---
Subject: Bug 28982
Author: rsandifo
Date: Wed Sep 13 06:30:59 2006
New Revision: 116919
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116919
Log:
gcc/
PR rtl-optimization/28982
* reload.c
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-09-13 06:32
---
Patch applied
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ian at airs dot com 2006-09-13 06:36 ---
When I run the demangler on
_ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE
I get
void jmain::main(JArrayjava::lang::String**)
The relevant patch went in on 2005-12-10 to libiberty/cp-demangle.c. Can you
confirm that
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-13 06:39 ---
(In reply to comment #3)
When I run the demangler on
_ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE
I get
void jmain::main(JArrayjava::lang::String**)
What happens when running it in Java mode (note the
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-13 06:46
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-13 06:56 ---
This one works for me but I doubt it is correct:
Index: ../../gcc/ipa-utils.c
===
--- ../../gcc/ipa-utils.c (revision 116919)
+++
--- Comment #5 from ian at airs dot com 2006-09-13 07:23 ---
OK, with -s java I get
jmain.main(java.lang.String[])void
I misunderstood Daniel's report. Sorry about that.
The fact that the function's return type is printed at the end is deliberate.
This is because -s java sets
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 07:57
---
The removed comment says:
- /* If will do cse, generate all results into pseudo registers
- since 1) that allows cse to find more things
- and 2) otherwise cse could produce an insn the machine
-
Hi!
I don't seem to be able to build the development sources (4.2.0 20060911) under
SGI ('uname -a': IRIX64 fuel3 6.5 01100304 IP35).
I've tried several things, but I keep getting the following error when
'bootstraping':
config.status: executing default commands
if [ x != x ] [ ! -d
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:18
---
There might be problems if no matching set can be found in the current
basic block. I'll have to think about how to best check for this.
I'm currently leaning to add a field in struct deps for the head of the
--- Comment #4 from pault at gcc dot gnu dot org 2006-09-13 08:21 ---
Bud,
Quite by chance, I had noticed the cause of this a couple of days ago; if you
look at the Doxygen documentation for gfc_data, you will see that the only
reference to the locus field 'where' is in
Compiling as C works, C++ fails. This worked with 20060823.
(sid)118:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O re-ru32un.c
re-ru32un.c: In function 'void LoadUserAlph(char*)':
re-ru32un.c:4: error: invalid operand to unary operator
[0];
re-ru32un.c:4: internal compiler error:
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:24
---
Roger, could you comment on Ramana's proposition? Thanks in advance.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:32
---
Please indicate whether it's a regression from earlier versions of GCC.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from irar at il dot ibm dot com 2006-09-13 08:32 ---
I think, the problem here is that we only check SMT and not NMT. I am preparing
a patch to fix this. NMT is stored in ptr_info_def of data-ref, and only if it
does not exist, SMT will be checked.
--
irar at il dot
--- Comment #5 from patchapp at dberlin dot org 2006-09-13 08:35 ---
Subject: Bug number PR29051
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-09/msg00496.html
--
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:37
---
If the ICE has disappeared on both branches, the testcase should be added to
the testsuite and the PR closed.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-13 08:44
---
Please indicate the version(s) of the compiler, whether it's a regression, etc.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from aph at gcc dot gnu dot org 2006-09-13 09:01 ---
I don't understand why this bug has been reported.
Are you using an up-to-date libiberty to do the demangling? When I try c++filt
--format java, I get
Hello.main(java.lang.String[])void
which is correct.
The
--- Comment #2 from andrew dot stubbs at st dot com 2006-09-13 09:23
---
(In reply to comment #1)
As you've written it, class C doesn't have any non-static members. Struct
C::s
hasn't been declared as a member object of C. const int i is a member of
C::s,
not C, so C() without
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-13
10:10 ---
(In reply to comment #5)
This is not DLL-related, the following code doesn't have the expected
behaviour
(although it works fine on i686-linux, even in the static case):
$ cat ctesti.c
#include
--- Comment #4 from bonzini at gnu dot org 2006-09-13 10:10 ---
PR19505 is fixed, is the patch still bad?
--
bonzini at gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0/4.1/4.2 regression]|[4.1/4.2 regression]
|procedure doesn't modify
--- Comment #1 from bonzini at gnu dot org 2006-09-13 10:43 ---
A somewhat disconnected comment on the ecj-branch build process...
Are you planning to distribute ecj as a JAR file too? If so, there should be
no changes to the documentation for building out of tarballs.
If you don't
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-13 11:39 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-09-13 11:41 ---
(gdb) run
Starting program: /abuild/rguenther/gcc41-g/gcc/cc1plus -quiet t.ii
Program received signal SIGSEGV, Segmentation fault.
0x080f565b in instantiate_decl (d=0xb7d9cf00, defer_ok=0,
Hi,
I got AN ICE trying to compile
--
module bcc
implicit none
private
type md_field
real,dimension(:,:),pointer :: position
end type md_field
real,dimension(1:3,1:2),parameter :: unitcell
= reshape((/ 0.25,0.25,0.25, 0.75,0.75,0.75 /),(/3,2/))
contains
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2006-09-13
12:20 ---
Andrew,
The proposed patch doesn't work. It converts the internal
compiler error into a compiler time error of...
gcc-4 -O3 -g -m64 array-9.c
array-9.c:7: error: declaration of 'x' as array of voids
Hi
I am using gcc 20060906 snapshot to compile a 2.6.10 kernel for a
Coldfire MCF5484 (and uclibc 0.9.28).
The question is that I was getting some errors like this:
{standard input}: Assembler messages:
{standard input}:22: Error: invalid instruction for this architecture;
needs ColdFire
--- Comment #7 from drow at gcc dot gnu dot org 2006-09-13 12:31 ---
Subject: Re: Libiberty demangler can not handle new Java mangling.
I don't understand why this bug has been reported.
The bug was reported because the combination of the mangling change and
the demangler postfix
--- Comment #8 from drow at gcc dot gnu dot org 2006-09-13 12:31 ---
Not a bug then.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-09-13 13:46 ---
(In reply to comment #4)
(In reply to comment #3)
Now we don't do that either but that is a different bug.
Actually we do reject it with -pedantic so that is not a different bug after
all but a change, a
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-13
13:52 ---
So I assume I just need to create a patch that adds...
* { dg-skip-if { powerpc*-*-darwin* } { -m64 } { } } */
to the darwin-bool-1.c testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29055
testserver.java in Jessie 1.0.1.
cmmand : gcj -v -c -o testserver.o testserver.java
Using built-in specs.
Reading specs from /usr/lib/gcc/i586-suse-linux/4.1.0/../../../libgcj.spec
rename spec lib to liborig
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix
--- Comment #1 from linh at mytum dot de 2006-09-13 14:16 ---
Created an attachment (id=12251)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12251action=view)
this testserver in jesssie-1.0.1 is compiled under classpath-0.92.
--
--- Comment #28 from hjl at lucon dot org 2006-09-13 15:03 ---
Apparently, your target_flags sets MASK_64BIT. You need to run gdb on cc1 and
set hardware watchpoint on target_flags to see where it sets MASK_64BIT:
[EMAIL PROTECTED] gcc]$ touch x.i
[EMAIL PROTECTED] gcc]$ gdb cc1
GNU
Consider following code:
//
1 int main(int argc, char** argv) {
2if (argc 1) {
3 goto finish;
4}
5 finish:
6int ret = 1;
7return ret;
8 }
//
Though I tested different versions of GCC (3.3.5, 3.4.4, 4.1.1), I was not able
to
valarray should undefine all temp macros, but it does not
$ cat test.cpp
#include valarray
$ g++-4.0 -E -dM test.cpp | grep _DEFINE_ | wc
2 5464236
$ g++-4.1 -E -dM test.cpp | grep _DEFINE_ | wc
2 5464236
$ g++-4.2 -E -dM test.cpp | grep _DEFINE_ | wc
2 546
--- Comment #1 from schwab at suse dot de 2006-09-13 15:32 ---
A label can only be part of a statement. A declaration is not a statement.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #3 from tobi at gcc dot gnu dot org 2006-09-13 16:06 ---
This is intriguing. Why would 'end' be treated any different from 'xxx'?
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bangerth at dealii dot org 2006-09-13 16:10 ---
Confirmed with the testcase from attachment #2.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #8 from tobi at gcc dot gnu dot org 2006-09-13 16:11 ---
This is another variation of the theme in 26227
*** This bug has been marked as a duplicate of 26227 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tobi at gcc dot gnu dot org 2006-09-13 16:11 ---
*** Bug 28443 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tobi at gcc dot gnu dot org 2006-09-13 16:12 ---
Again, the same theme as 26227.
*** This bug has been marked as a duplicate of 26227 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tobi at gcc dot gnu dot org 2006-09-13 16:12 ---
*** Bug 28809 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:17 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-13 16:20
---
(In reply to comment #13)
If the ICE has disappeared on both branches, the testcase should be added to
the testsuite and the PR closed.
But the bug still exists, just was covered up by my tree-inline patches for
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-13 16:22 ---
(In reply to comment #5)
Andrew,
The proposed patch doesn't work. It converts the internal
compiler error into a compiler time error of...
Yes the patch does work as this is invalid code to begin with :).
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:27 ---
_D is in the reserved identifier space IIRC so I think this is a non bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29063
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-13 16:45 ---
I tried this with 4.1 (failed due to missing imports), the RH 4.1 (worked)
and svn head (worked). So, I think we would need more information to
proceed.
--
tromey at gcc dot gnu dot org changed:
What
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 16:49 ---
I am thinking SUSE created their 4.1.0 before 4.1.0 was release, I think this
is the same as PR 25366.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29061
--- Comment #2 from pcarlini at suse dot de 2006-09-13 16:51 ---
As a matter of fact valarray *always* undefines the macros, besides in those
two specific cases (and the first one is even undefined weren't for a typo ;)
So, we can as well do the two-lines change...
--
pcarlini at
--- Comment #6 from janis at gcc dot gnu dot org 2006-09-13 16:54 ---
Benjamin, I had tried that, but it adds timeout=300 to the options passed to
the compiler. Does it really work for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 16:56 ---
UX:make: ERROR: don't know how to make regex.c (bu42).
This sounds like you are not using GNU make which is required.
Can you try again this time using GNU make?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from linh at mytum dot de 2006-09-13 16:59 ---
(In reply to comment #2)
I tried this with 4.1 (failed due to missing imports), the RH 4.1 (worked)
and svn head (worked). So, I think we would need more information to
proceed.
I compiled this with 4.1, Suse 10.1.
Now
--- Comment #5 from tromey at gcc dot gnu dot org 2006-09-13 17:17 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-13 17:37
---
But the bug still exists, just was covered up by my tree-inline patches for PR
28075.
Your patch may simply be the fix. If we have no testcase, we have no bug.
--
--- Comment #4 from mbo dot massimo at tiscali dot it 2006-09-13 18:03
---
I have installed the fix and the problem is now resolved.
I have tested it on a large program and it is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
This code snippet:
class X
{
~X() {}
void f ()
{
X::~X ();
}
};
violates clause 12.4 ; 12 (explicit destructor calls must use a member
access operator) . However, the diagnostic given is somewhat confusing:
dstr.c: In member function void X::f():
dstr.c:6: error: no matching
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:09
---
I have installed the fix and the problem is now resolved.
I have tested it on a large program and it is OK.
Great, thanks for the feedback.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
--- Comment #2 from janis at gcc dot gnu dot org 2006-09-13 18:13 ---
A regression hunt on powerpc-linux identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=116656
r116656 | jakub | 2006-09-02 06:55:09 + (Sat, 02 Sep 2006)
Interestingly enough, I've
Given the test case below, it appears that while a pointer to a member function
(PTMF) is initialized properly, the check against a NULL pointer still fails.
The same case passes properly on x86 and SH4 - it appears to be an ARM ABI
detail which causing the heartburn.
In most platforms, the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 18:25 ---
Is this really the arm eabi C++ ABI and not really the arm C++ ABI?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:27
---
Subject: Bug 21952
Author: ebotcazou
Date: Wed Sep 13 18:27:24 2006
New Revision: 116926
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116926
Log:
PR ada/21952
* gigi.h
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:27
---
Subject: Bug 21952
Author: ebotcazou
Date: Wed Sep 13 18:27:46 2006
New Revision: 116927
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116927
Log:
PR ada/21952
* gigi.h
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:29
---
Fixed in upcoming 4.1.2 release.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-13 18:29 ---
Actually that is incorrect and this code is really valid by DR 272.
This is a dup of bug 12333 which is about rejecting this code.
*** This bug has been marked as a duplicate of 12333 ***
--
pinskia at gcc dot
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-13 18:29
---
*** Bug 29065 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from amallory at qnx dot com 2006-09-13 18:30 ---
(In reply to comment #1)
Is this really the arm eabi C++ ABI and not really the arm C++ ABI?
ARM eabi is an alias for the ABI for the ARM Architecture. Do you have
anything on point to help clairify the issue?
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-13 18:34 ---
(In reply to comment #2)
A regression hunt on powerpc-linux identified the following patch:
This is what I was expecting actually, I might look at this later, we might
just need a fold (read from constant string)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|4.1.2 |---
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:40
---
Subject: Bug 28591
Author: ebotcazou
Date: Wed Sep 13 18:40:26 2006
New Revision: 116928
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116928
Log:
PR ada/28591
* decl.c
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2006-09-13
18:41 ---
Okay. I'll run a complete make check tonight to verify
that the patch introduces no regressions in at least
the c, c++ and fortran language build. Assuming no
regressions, do you want to submit the patch
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:42
---
Fixed on mainline.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:48
---
Subject: Bug 29025
Author: ebotcazou
Date: Wed Sep 13 18:48:21 2006
New Revision: 116929
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116929
Log:
PR ada/29025
* trans.c
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:48
---
Subject: Bug 29025
Author: ebotcazou
Date: Wed Sep 13 18:48:46 2006
New Revision: 116930
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116930
Log:
PR ada/29025
* trans.c
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-13 18:50
---
Fixed in upcoming 4.1.2 release.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pbrook at gcc dot gnu dot org 2006-09-13 19:00 ---
This is looking like a latent reload bug.
I don't see anything in r105121 that could cause this bug. I can reproduce it
on non-linux and non-eabi arm targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
gfortran fails on the attached subroutine.
gfortran -v -save-temps -c ircmva.f
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-13 20:11 ---
Yes, it appears to be related to spread. If you comment out the
spread() in the subroutine the compiles. Additionally, if you
change x%position(:,1:2) to x%position(1:3,1:2), then the
code compiles. So, it looks
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-13 20:17 ---
This compiles with gfortran 4.2, so you may want to update to a
newer compiler.
Does this file contain any TAB characters?
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from mathieu dot courtois at free dot fr 2006-09-13 20:18
---
Created an attachment (id=12252)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12252action=view)
source code
add source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
On mainline I'm getting a bootstrap failure building in the libjava directory
on sparc-sun-solaris2.10:
Undefined first referenced
symbol in file
GC_get_thread_stack_base./.libs/libgcj.so
ld: fatal: Symbol referencing errors. No
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-09-13 20:28
---
Same on SPARC/Solaris 8 and 9.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sje at cup dot hp dot com 2006-09-13 20:32 ---
I had someone try to use 64 bit PA GCC code with HP Java and they ran into two
unsats, __cxa_finalize and _Jv_RegisterClasses. In GCC 4.0.3 there is a weak
definition of __cxa_finalize in libstdc++.sl, but in GCC 4.1.1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-13 20:36 ---
This is why I mentioned Java people should not be committing new features this
late.
See also:
http://gcc.gnu.org/ml/java/2006-09/msg00021.html
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from sje at cup dot hp dot com 2006-09-13 20:37 ---
Well, I guess I should have read comment 1 before adding comment 2,
sorry for the extra mail David.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28821
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-13 20:40
---
Please, Andrew, stop overwriting my changes. Thanks.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
When gcc, g++, etc ouputs errors they are in a form designed to help people
read the command line. With many people wanting to use IDEs, such as Eclips
CDT, trying to write code to parse this output is not easy.
For this reason to have a mode where the compiler and other gcc tools can
output
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-13 20:45 ---
(In reply to comment #3)
Please, Andrew, stop overwriting my changes. Thanks.
If the bugzilla would allow me to merge the changes, it would be better but it
does not. Also I loaded the page right before you
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-13 20:48
---
If the bugzilla would allow me to merge the changes, it would be better but it
does not. Also I loaded the page right before you changed stuff and I had
changed the summary to include [4.2 Regression] but
1 - 100 of 179 matches
Mail list logo
