[Bug libgcj/14572] System ClassLoader is not set according to java.system.class.loader property

--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-15 20:48 --- The bug here is that our built-in system class loader is not initialized when the user-specified system class loader is looked for. So, the class path is not searched and the class is not found. Fixing this

[Bug c/22052] [4.0/4.1 Regression] redefinition of inline function succeeds

--- Additional Comments From echristo at redhat dot com 2005-06-15 20:49 --- OK. This diff works, and passes bootstrap with no regressions for both --enable-intermodule and normally on x86-linux. The --enable-intermodule bits are why we split this out in the first place, but same_transla

[Bug target/22083] New: TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

gcc/config/rs6000/aix51.h and gcc/config/rs6000/aix52.h both define TARGET_C99_FUNCTIONS. This seems to be wrong for AIX 5.1: it has xxxl functions, but not xxxf ones. Source code: === CUT === extern double sqrt(double); float f(float x) { return sqrt(x); } int main() { return f(1.0f) != 1.

[Bug middle-end/22072] bizarre code for int*int/2

--- Additional Comments From felix-gcc at fefe dot de 2005-06-15 21:05 --- (In reply to comment #5) > (In reply to comment #4) > > what about *arithmetic shift* instruction (e.g. SAR on ix86) ? > Nope, try that with a negative number and you will notice that it will not > work. Actuall

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 21:05 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 OK, so do we now agree it works with 4.0.0, but not with 4.0-branch? You claim "That is because it is picking up the libgcc_s.dylib which

[Bug c++/3187] gcc lays down two copies of constructors

--- Additional Comments From larue at cadence dot com 2005-06-15 21:09 --- This problem makes it difficult to debug C++ code. This is affecting the systemC (www.systemc.org) community. It is more than a minor issue those debugging C++. -- What|Removed

[Bug middle-end/19616] missed tail call

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 21:14 --- (In reply to comment #14) > And how can I check whether your explanation is true? (On linux I > have ldd for such a task; do you know if there is something similar > for darwin?) "otool -L" -- http:

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 21:15 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 Already tried it and it doesn't do what I think we want: /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load - weak_reference_mismatch

[Bug middle-end/22072] bizarre code for int*int/2

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 21:18 --- (In reply to comment #6) > SAR r/m32, 1Signed divide* r/m32 by 2, once Huh, I think that is wrong, witness: #include int f(int a) { return a >> 1; } int main(void) { int g = f(-5); printf("%d\n"

[Bug c++/3187] gcc lays down two copies of constructors

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 21:19 --- (In reply to comment #17) > This problem makes it difficult to debug C++ code. This is affecting the > systemC (www.systemc.org) community. It is more than a minor issue those > debugging C++. The debuger

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 21:21 --- (In reply to comment #16) > Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 > > Already tried it and it doesn't do what I think we want: That means otool does not support 64bit, I think the

[Bug java/20697] Invalid Can't find method error on call to super

--- Additional Comments From mckinlay at redhat dot com 2005-06-15 21:43 --- I'm testing a fix. This is a different problem to 18131. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20697

[Bug java/20697] Invalid Can't find method error on call to super

--- Additional Comments From mckinlay at redhat dot com 2005-06-15 21:44 --- Err, 18119 I mean. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20697

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 21:48 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 Great, thanks. Here is what otool64 -L reports for a binary built with [descartes:~/programs/gcc-4.0.0/objdir] lucier% /pkgs/gcc-4.0.0-ne

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 21:57 --- (In reply to comment #18) > Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 > > Great, thanks. > > Here is what otool64 -L reports for a binary built with That does not make sense as it sh

[Bug target/22006] New IRIX 6.5 testsuite failures with gas: .space repeat count is zero, ignored

--- Additional Comments From echristo at redhat dot com 2005-06-15 21:58 --- Did you happen to catch where the .space 0 were being emitted from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22006

[Bug target/22006] New IRIX 6.5 testsuite failures with gas: .space repeat count is zero, ignored

--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-06-15 22:01 --- Subject: Re: New IRIX 6.5 testsuite failures with gas: .space repeat count is zero, ignored echristo at redhat dot com writes: > Did you happen to catch where the .space 0 were being emitted from

[Bug java/22060] javax/swing/text/InternationalFormatter.clone() doesn't compile (GNU Classpath)

--- Additional Comments From mckinlay at redhat dot com 2005-06-15 22:07 --- *** This bug has been marked as a duplicate of 20697 *** -- What|Removed |Added St

[Bug java/20697] Invalid Can't find method error on call to super

--- Additional Comments From mckinlay at redhat dot com 2005-06-15 22:07 --- *** Bug 22060 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug target/22077] vec_all_eq does not produce good result

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 22:11 --- I should have written we want the following code gen: vcmpeqfp. v3,v2,v3 li r3,3245 bnelr+ cr6 li r3,12 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22077

[Bug target/22077] vec_all_eq does not produce good result

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 22:21 --- Hmm, Apple's 3.3 compiler gets it right: vcmpeqfp. v3,v2,v3 li r3,3245 bltlr- cr6 li r3,12 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22077

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 22:31 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 On Jun 15, 2005, at 4:57 PM, pinskia at gcc dot gnu dot org wrote: > That does not make sense as it should always include libgcc_s for >

[Bug libgcj/17536] wrong ClassLoader for int[]

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-15 22:36 --- Subject: Bug 17536 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-15 22:36:01 Modified files: libjava: ChangeLog Added files: libja

[Bug target/22077] [4.0/4.1 Regression] vec_all_eq does not produce good result

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 22:38 --- 3.4.4 on powerpc-darwin gives: vcmpeqfp. v3,v2,v3 li r3,3245 crnot 26,24 bnelr- cr6 li r3,12 blr so this is a regression. -- What|Removed

[Bug java/22011] converting jar files into .so library in win32

--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-15 22:42 --- I'm not sure that building a shared library with gcj on windows is supported. (But I'm not an expert on our windows port.) Can you provide more information about this failure? A stack trace might help. Or

[Bug target/22077] [4.0/4.1 Regression] vec_all_eq does not produce good result

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 22:42 --- There is an extra RTL in .expand: (insn 15 14 16 1 (set (reg:SI 119 [ D.1317 ]) (reg:SI 123)) -1 (nil) (nil)) So this might not be a target bug after all. -- http://gcc.gnu.org/bugzilla/show

[Bug target/22077] [4.0/4.1 Regression] vec_all_eq does not produce good result

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 22:53 --- This does not look like target bug after all. The extra move does not matter as it is removed in the 3.4/ 4.0 case before getting to .combine: int foo(vector float x, vector float y) { int t = vec_all_eq(x

[Bug libgcj/22084] New: Divide_1 test case hangs

The Divide_1 test case now apparently hangs, printing: set_ld_library_path_env_vars: ld_library_path=.:/home/tromey/gnu/Trunk/build/i686-pc-linux-gnu//libjava/.libs:/home/tromey/gnu/Trunk/build/gcc 0 -2147483648 50354022 GC Warning: Repeated allocation of very large block (appr. size 258048):

[Bug target/22077] [4.0/4.1 Regression] vec_all_eq does not produce good result

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 23:07 --- The preprocessing source for the mainline is: int foo(__attribute__((altivec(vector__))) float x, __attribute__((altivec(vector__))) float y) { if (__builtin_vec_vcmpeq_p (2, (x), (y))) return 3245;

[Bug target/22085] New: [4.1 Regression] error with

Try the following code with -maltivec -fpreprocessed: int foo(__attribute__((altivec(vector__))) float x, __attribute__((altivec(vector__))) float y) { if (__builtin_vec_vcmpeq_p (2, (x), (y))) return 3245; else return 12; } -- Summary: [4.1 Regression] error with

[Bug target/22085] [4.1 Regression] error with -fpreprocessed

-- What|Removed |Added CC||bonzini at gcc dot gnu dot ||org Summary|[4.1 Regress

[Bug target/22085] [4.1 Regression] error with -fpreprocessed

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 23:09 --- I get the following error: t.i: In function 'foo': t.i:3: error: unresolved overload for Altivec builtin '__builtin_vec_vcmpeq_p' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22085

[Bug target/22077] [4.0/4.1 Regression] vec_all_eq does not produce good result

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 23:10 --- (In reply to comment #8) > The preprocessing source for the mainline is: Note don't use -fpreprocessed because there is a bug which causing that fail, see PR 22085. -- http://gcc.gnu.org/bugzilla/show_

[Bug preprocessor/22086] New: void * dereferenced in sizeof() yields 1

To my surprise, I was able to compile the following code snippet: void * pv = NULL; printf("sizeof: %d\n", sizeof(*pv)); I believe there are two problems here. First, I should not be able to dereference a void pointer, as I do inside sizeof(). Secondly, even if I could, should it

[Bug preprocessor/22086] void * dereferenced in sizeof() yields 1

--- Additional Comments From jboone at logitel dot com 2005-06-15 23:47 --- Created an attachment (id=9096) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9096&action=view) C sample -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22086

[Bug preprocessor/22086] void * dereferenced in sizeof() yields 1

--- Additional Comments From jboone at logitel dot com 2005-06-15 23:48 --- Created an attachment (id=9097) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9097&action=view) Intermediate output from gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22086

[Bug c/22086] void * dereferenced in sizeof() yields 1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 23:50 --- This is a GCC extension. sizeof(void) is invalid C and should error out and does with -pedantic-errors The reason why it is 1 and not 0 is because it is also a GNU extension that you can increment a void

[Bug c/22086] void * dereferenced in sizeof() yields 1

--- Additional Comments From jboone at logitel dot com 2005-06-16 00:03 --- Subject: Re: void * dereferenced in sizeof() yields 1 My apologies. And thanks for the polite explanation. I'll wade through the man pages and start using a more appropriate set of compile options. Thanks,

[Bug fastjar/22012] fastjar -C gets confused with more than one argument

--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-16 01:38 --- This is actually how jar is supposed to work. It is silly, but afaics the JDK jar works the same way. I'm closing the PR for this reason. FWIW I had to add another argument and I get this: opsy. jar -cvf q

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From giovannibajo at libero dot it 2005-06-16 01:56 --- This is a blatant case of a bug which surely requires more investigation and surely a bit more respect towards the submitter, who is helpful and is providing good reports. -- What|Removed

[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-16 01:58 --- See on why this is a dup of bug 21757. *** This bug has been marked as a duplicate of 21757 *** -- What|Removed |Added

[Bug target/21757] 64bit multilib for ppc-darwin

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-16 01:58 --- *** Bug 22082 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21757

[Bug libstdc++/22087] New: ctype tables are offset by one on DJGPP

On DJGPP, rather than _M_table pointing to the mask for '\0', it points to the mask for EOF. It is then offset by one in ctype::is(mask, char), but not in ctype::is(const char*, const char*, mask*), ctype::table() or in the constructor mask* parameter. (ctype::classic_table() returns 0.) The con

[Bug tree-optimization/22056] gcc.dg/pr14796-2.c scan-tree-dump c & -34359738368 fails

--- Additional Comments From phython at gcc dot gnu dot org 2005-06-16 02:51 --- According to the results posted to gcc-testresults, this only effects i386. Also a cross-compiler from ia64-linux to i386-elf doesn't show a problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22056

[Bug libgcj/19877] sometimes reconfiguring leads to incorrect config.h

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-16 03:20 --- Tom -- What|Removed |Added CC||bkoz at gcc dot gnu

[Bug libgcj/19877] sometimes reconfiguring leads to incorrect config.h

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-16 03:23 --- Tom, what am I doing wrong? I seem Mike Stump checking in these kinds of cleanup of reconfigured files as well. Currently I'm using mainline/gcc-4_0 autoconf 2.59 automake 1.9.3 gcc-3_4-branch autoconf 2.59

[Bug libgcj/19877] sometimes reconfiguring leads to incorrect config.h

--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-16 03:46 --- The versions you're using all look right. In this case I regenerated configure and whatnot due to a change in config/. I haven't been using autoreconf though; I've been running the tools by hand, looking in

GCC-ANSI C conflict

hi according to ansi c standards all declarations have to to be at the starting of the block.. which means the program below should not work.. i compiled this using gcc >>gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4) >>Copyright (C) 2004 Free Software Foundation, Inc. >>This is free software; see

Apparent erratic rescanning of ,## construct in cpp 3.2.x

This input: -- #define a(x,...) a1(x,__VA_ARGS__) #define b(x,...) b1(x,##__VA_ARGS__) a(a(1,2),a(3,4)) //1 a(a(1,2),b(3,4)) //2 b(b(1,2),a(3,4)) //3 b(b(1,2),b(3,4)) //4 --

<    1   2