--- Comment #9 from igodard at pacbell dot net 2006-04-20 08:20 ---
I believe it is a bug because my declaration should not be able to hijack the
use inside the STL, which should only be seeing the declarations that were
visible where the STL function was defined, which did not include a
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-20 08:44 ---
(gdb) call debug_generic_expr(stmt)
*(struct VectorD.1984 *) D.2012 = dD.1989
that's not gimple. We trip over that in into-ssa.
(gdb) call debug_bb_n(2)
;; basic block 2, loop depth 0, count 0
;; prev block 0, nex
--- Comment #10 from pcarlini at suse dot de 2006-04-20 09:10 ---
Well, two comments: first, I cannot reproduce with current mainline. Second,
frankly, if the implication of the issue is that in the entire implementation
of we cannot use operator, only to allow the user to write
unrestr
--- Comment #11 from pcarlini at suse dot de 2006-04-20 09:25 ---
(In reply to comment #10)
Before closing this I'm only curious
to
> know why mainline is fine, maybe, simply, ADL was too zelant here? Any
> language
> lawyer kicking in?
The rea
--- Comment #12 from igodard at pacbell dot net 2006-04-20 09:28 ---
I don't think that the problem is in the STL. The STL can be as tricky as it
wants, including use of operator,(). It should not be possible for the actual
operator,()s I declared to hijack the STL the way that happened,
--- Comment #13 from igodard at pacbell dot net 2006-04-20 09:31 ---
p.s. Another requirement for the failure probably is that the second
declaration has to be a templated operator,() of the form I used i.e. right
argument a free template argument.
Ivan
--
http://gcc.gnu.org/bugzil
--- Comment #14 from pcarlini at suse dot de 2006-04-20 09:37 ---
(In reply to comment #12)
> I don't think that the problem is in the STL. The STL can be as tricky as it
> wants, including use of operator,(). It should not be possible for the actual
> operator,()s I declared to hijack t
My compiled program crashes when it receives many SIGNALs 19 from outside. It
also crashes when another signal is used, if the 'disposition f(int)' is set on
it.
Sun Solaris 8 on intel 2*CPU Pentium III Xeon.
GCC is from the sunfreeware.com bundle.
I tries it on the "Sun Solaris 8 on 1*CPU UltraS
--- Comment #1 from ademin at gmail dot com 2006-04-20 09:38 ---
Created an attachment (id=11302)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11302&action=view)
.ii file of test case program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27223
--- Comment #5 from aph at gcc dot gnu dot org 2006-04-20 09:39 ---
Subject: Bug 25414
Author: aph
Date: Thu Apr 20 09:39:22 2006
New Revision: 113113
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113113
Log:
2006-04-05 Archit Shah <[EMAIL PROTECTED]>
PR java/25414
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 09:54 ---
This is more likely a problem with your kernel/libc than with libstdc++ or gcc.
Also on linux i386 signal 19 is SIGSTOP, for which sigset returns SIG_HOLD.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #15 from pcarlini at suse dot de 2006-04-20 09:56 ---
We can easily get a reference to the user defined operator, from the mainline
compiler with:
template
int operator,(int i, T t) { return i; }
#include
int main()
{
std::vector v;
std::fill_n(v.begin(), 0, 1);
}
--- Comment #16 from igodard at pacbell dot net 2006-04-20 09:57 ---
Well, I don't see how the templating of the STL code can influence whether or
not my declarations are in scope or not.
BTAIM, my declarations are certainly inappropriate for what the STL is looking
for at the call site
--- Comment #17 from igodard at pacbell dot net 2006-04-20 09:58 ---
Yes, you pick up my operator in Wolfgang's test case. But in the original
submission the vector code is *before* my operators, which are consequently out
of scope for the STL code
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #3 from ademin at gmail dot com 2006-04-20 10:12 ---
(In reply to comment #2)
> This is more likely a problem with your kernel/libc than with libstdc++ or
> gcc.
> Also on linux i386 signal 19 is SIGSTOP, for which sigset returns SIG_HOLD.
>
Now I tried it with signal 17.
--- Comment #18 from pcarlini at suse dot de 2006-04-20 10:20 ---
This is a self-contained example:
namespace mine1
{
struct mini_iter
{
mini_iter(int* p)
: _M_current(p) { }
int&
operator*() const
{ return *_M_current; }
mini_iter&
operator++()
{
--- Comment #13 from jakub at gcc dot gnu dot org 2006-04-20 10:27 ---
This has been introduced in
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01594.html
Will try to revert the name-lookup.c part and see what exactly breaks and if
we couldn't tell about this to cgraph rather than doing
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-20 10:45
---
Mark, your patch doesn't cover the following case which still crashes
on mainline:
===
template void T::X::foo() {}
===
The ICE is n
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-20 10:49 ---
I would suggest using SIGUSR1 for testing, malloc and free are not affected by
signal interruption. So if they are, this is internal to the Solaris libc or
the kernel. At a first guess I would suggest updating the
The compiler doesn't warn when you read a variable twice in an expression where
you also write it.
Look at http://www.research.att.com/~bs/bs_faq2.html#evaluation-order to see
the description of the problem.
(GCC) 3.4.4 (mingw special)
c++ -Wall -pedantic -ansi
--
Summary: Read twic
--- Comment #5 from wouter dot vermaelen at pi dot be 2006-04-20 10:58
---
I think something similar happens for the following code.
int f(int a) {
switch (a & 7) {
case 0: return 2;
case 1: return 3;
case 2: return 5;
case 3: return 7;
case 4:
The following program should not raise Program_Error, but does.
procedure p is
procedure (txt: WIDE_STRING) is
pragma Assert(txt'length > 0, "string is empty");
result: WIDE_STRING(txt'first .. txt'first + 3);
begin
result(txt'first .. txt'first + 3) := "";
--- Comment #1 from bauhaus at futureapps dot de 2006-04-20 11:28 ---
I forgot:
$ gnatmake p
$ ./p
raised PROGRAM_ERROR : p.adb:11 explicit raise
(The Assert is a relic of an earlier program
and not an issue.)
--
bauhaus at futureapps dot de changed:
What|Removed
--- Comment #19 from pcarlini at suse dot de 2006-04-20 11:32 ---
By the way, I think I mentioned incorrectly ADL, which, in this specific case,
doesn't seem involved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
--- Comment #12 from patchapp at dberlin dot org 2006-04-20 11:45 ---
Subject: Bug number PR27084
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-04/msg00750.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #20 from pcarlini at suse dot de 2006-04-20 11:56 ---
Everything considered, I don't think there is something to fix here, either in
the compiler (and all the other compilers I tried bahaves the same of current
g++ on Comment #18, irrespective of the position of the overloade
--- Comment #21 from pcarlini at suse dot de 2006-04-20 11:59 ---
(In reply to comment #20)
std::fill_n could be made more robust
> restricting the second template argument,
Scratch this bit, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #14 from jakub at gcc dot gnu dot org 2006-04-20 12:04 ---
The reversal of the DECL_UID (x) = DECL_UID (t); assignment in name-lookup.c
causes
FAIL: g++.dg/opt/inline2.C (test for excess errors)
as well as
// { dg-do link }
// { dg-options "-O1" }
static int g;
void f()
{
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-20 12:04 ---
It's called -Wsequence-point, but it's not perfect. See also PR18050.
int *v;
int i;
void f(int, int);
void foo(void)
{
v[i] = i++;
f(v[i], i++);
}
/space/rguenther/install/gcc-3.4.4/bin/gcc -Wsequence-point -
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 12:05 ---
Oh, you used C++ but filed against C. Reopen bug...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-20 12:06 ---
... to close as fixed in 4.0.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-20 13:52 ---
I have a patch to teach GVN tree-combining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27090
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-20 13:54 ---
Which, for the testcase in comment #4 gives us
;; Function f (f)
Created value VH.0 for a_1
Created value VH.1 for *VH.0 vuses: (SMT.4_8)
Created value VH.2 for (unsigned int *) VH.0
Created value VH.3 for (int *)
--- Comment #22 from bangerth at dealii dot org 2006-04-20 14:10 ---
(In reply to comment #17)
> Yes, you pick up my operator in Wolfgang's test case. But in the original
> submission the vector code is *before* my operators, which are consequently
> out
> of scope for the STL code
Tha
--- Comment #4 from moura at kdewebdev dot org 2006-04-20 14:49 ---
One has still to use the -Wsequence-point, in C++?
It would be good if there was no need to explicitly use such a switch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27224
--- Comment #3 from laszlo dot szakony at philips dot com 2006-04-20 14:52
---
Created an attachment (id=11303)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11303&action=view)
Simple test without automake files to test visibility changes of static members
To create the binaries
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-20 14:57
---
We now generate
return (int) ((unsigned int) (long long int) b + (unsigned int) (long long
int) a);
which is harder to optimize. But with -fwrapv and GVN tree-combiner we get
aa_2 = (long long int) a_1;
b
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-20 15:42 ---
Subject: Bug 21941
Author: tromey
Date: Thu Apr 20 15:42:12 2006
New Revision: 113117
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113117
Log:
PR libgcj/21941:
* gnu/java/net/natPlainDatagra
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-20 15:46
---
Mine.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassig
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-20 15:46 ---
Subject: Bug 21941
Author: tromey
Date: Thu Apr 20 15:46:40 2006
New Revision: 113118
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113118
Log:
PR libgcj/21941:
* gnu/java/net/natPlainDatagra
--- Comment #3 from tromey at gcc dot gnu dot org 2006-04-20 15:47 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #3 from patchapp at dberlin dot org 2006-04-20 15:50 ---
Subject: Bug number PR c++/19963
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-04/msg00761.html
--
http://gcc.gnu.org/bugzil
The compiler used to use move_by_pieces for sh-elf at -O2 for the trivial
strcpy calls in dhrystone, but now it uses memcpy. I've found that this
is because it no longer knows that the two MEM arguments are aligned.
Here is a pruned-down testcase:
char *strcpy (char *, const char *);
extern void
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-20 15:54 ---
You can see it by compiling this short example
program with 'g++ --syntax-only':
#include
#include
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-04-20 15:58 ---
This worked in 3.5.0 20040512 (experimental), but failed in 3.5.0 20040630
(experimental)
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-04-20 16:01
---
Subject: Bug 26789
Author: reichelt
Date: Thu Apr 20 16:01:05 2006
New Revision: 113119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113119
Log:
PR mudflap/26789
* tree-mudflap.c (mudflap
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-20 16:02 ---
(In reply to comment #1)
> This should be fairly straight forward to implement. The
> question is where do we put the module and 8.o file. Is
> ${prefix}/lib/modules a good enough place? There i
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-20 16:05 ---
You might want to dive into builtins.c:get_pointer_alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-20 16:06 ---
You can see it by compiling this short example
program with 'g++ --syntax-only':
#include
#include
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27201
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-20 16:06 ---
Ignore that, I appended to the wrong report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27219
--- Comment #9 from law at gcc dot gnu dot org 2006-04-20 16:13 ---
Subject: Bug 26854
Author: law
Date: Thu Apr 20 16:13:12 2006
New Revision: 113120
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113120
Log:
PR tree-optimization/26854
* tree-ssa-dse.c (dse_opt
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-20 16:15 ---
And this is the wrong place for help with signals anyways, please first ask in
a solaris specific mailing list or news group.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from law at redhat dot com 2006-04-20 16:17 ---
PRE/FRE for mainline need some TLC on their compile-time performance as
indicated by this PR as well. They're #3 & #4 respectively behind the operator
scanning code and store-ccp and way out of line when compared with the r
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-04-20 16:19
---
Subject: Bug 26789
Author: reichelt
Date: Thu Apr 20 16:19:21 2006
New Revision: 113121
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113121
Log:
PR mudflap/26789
* tree-mudflap.c (mudflap
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-04-20 16:19
---
(In reply to comment #14)
> The reversal of the DECL_UID (x) = DECL_UID (t); assignment in name-lookup.c
> causes
Yes because they are the same decl, if the C++ only uses one decl instead of
creating a seperate on
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-04-20 16:21
---
(In reply to comment #10)
> PRE/FRE for mainline need some TLC on their compile-time performance as
> indicated by this PR as well. They're #3 & #4 respectively behind the
> operator
> scanning code and store-ccp
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-04-20 16:24
---
Actually I don't see why the comma operator can be overridden in C++ (yes this
I am raising a question about why the standards says it can).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-20 16:24
---
Now also fixed on the 4.1 branch.
The more drastic fix used there (skipping the whole function on errors
instead of just single erroneous objects) is now also on mainline, too.
--
reichelt at gcc dot gnu dot o
--- Comment #24 from law at redhat dot com 2006-04-20 16:24 ---
Richard -- is there any chance you could pick up the ball on this PR? I really
need to focus on some non-GCC stuff for a while, but don't want this issue to
get lost in the process.
Jeff
--
http://gcc.gnu.org/bugzilla
--- Comment #25 from rguenther at suse dot de 2006-04-20 16:33 ---
Subject: Re: VRP/DOM does not like TRUTH_AND_EXPR
On Thu, 20 Apr 2006, law at redhat dot com wrote:
> Richard -- is there any chance you could pick up the ball on this PR? I
> really
> need to focus on some non-GCC s
--- Comment #2 from bauhaus at futureapps dot de 2006-04-20 16:57 ---
Apperently, this is fixed in the 4.2 trunk, 113114.
Same error with 4.02. (Not in 3.4.5 of GNAT GPL edition)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27225
--- Comment #3 from r_ovidius at eml dot cc 2006-04-20 17:20 ---
Try with
String url = "ftp://gcc.gnu.org";;
(notice the missing "/" at the end). This results in
gnu.java.net.protocol.ftp.FTPException: Invalid number of arguments.
at gnu.java.net.protocol.ftp.FTPConnection.change
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-20 18:05 ---
(In reply to comment #2)
> You might want to dive into builtins.c:get_pointer_alignment.
>
Hmm, indeed, I see that in 3.5.0 20040512, expand_builtin_memcpy
has found a dest_align of 32 and proceeded to go the store
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-04-20 18:10 ---
Created an attachment (id=11304)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11304&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
--- Comment #24 from bangerth at dealii dot org 2006-04-20 18:16 ---
(In reply to comment #23)
> Actually I don't see why the comma operator can be overridden in C++ (yes this
> I am raising a question about why the standards says it can).
It was mid-March when Stroustrup developed oper
--- Comment #25 from igodard at pacbell dot net 2006-04-20 18:40 ---
Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why
operator,() was overloadable in the Rationale.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-04-20 18:58 ---
(In reply to comment #4)
> Created an attachment (id=11304)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11304&action=view) [edit]
> proposed patch
>
Needs some more work.
--
http://gcc.gnu.org/bugzilla
--- Comment #26 from igodard at pacbell dot net 2006-04-20 19:15 ---
Sorry, fat fingered a submit before message was done, please ignore immediately
previous message. Corrected full one follows later
Ivan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
Testcase:
namespace x {
extern "C" const int y;
};
using x::y;
extern "C" int const y=0;
---
The testcase is orginally from Alex Rosenberg on the IRC channel, modified to
make it valid code so that the linkage specifications match.
This used to work before 4.0.0
--
Summary: [4.0
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-04-20 20:38 ---
Created an attachment (id=11305)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11305&action=view)
proposed patch for 4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27226
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-20 20:47 ---
I suggest you test on an architecture that traps on unaligned accesses, so as
ia64 with the correct prctrl setup. In particular you seem to miss that
ARRAY_REF can have a custom index range that doesn't start with z
Originally from jsch (jcraft.com)
com/jcraft/jsch/jce/DH.java
getE()
This function works in Sun's java, but on libgcj it fails. Here is a
standalone sample that works in Sun's java:
(I believe this used to work with gnu.crypto)
gcj (GCC) 4.2.0 20060419 (experimental)
gcj --main=Sec -o Sec S
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-20 20:53 ---
I have tested this test case again with lcm.c patched with the patch below to
check for insertions on edges where an expression is already available. The
abort does not trigger.
The version of GCC that I patched and
--- Comment #8 from amylaar at gcc dot gnu dot org 2006-04-20 21:09 ---
(In reply to comment #7)
> I suggest you test on an architecture that traps on unaligned accesses, so as
> ia64 with the correct prctrl setup.
I don't have access to an ia64 host, but sh-elf is a STRICT_ALIGNMENT ta
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-20 21:13 ---
Created an attachment (id=11306)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11306&action=view)
CFG at the start of gcse
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
--- Comment #9 from steven at gcc dot gnu dot org 2006-04-20 21:14 ---
Created an attachment (id=11307)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11307&action=view)
LCM dataflow solution for the first gcse pass
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
--- Comment #10 from steven at gcc dot gnu dot org 2006-04-20 21:15 ---
Created an attachment (id=11308)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11308&action=view)
LCM dataflow solution for the second gcse pass
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
--- Comment #11 from steven at gcc dot gnu dot org 2006-04-20 21:16 ---
One of these days someone should manually compute the LCM sets from attachments
1, 2, and 3 ...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-20 21:23 ---
Ah, I see. I only looked at the mainline patch. I was refering to the patch
for PR26565 which is still pending for 4.1 and will bring the 4.1 version
in-line with the mainline version. I guess sh is also affected
Test gfortran.dg/char_transpose_1.f90 fails on mainline for
powerpc-unknown-linux-gnu with optimization:
/home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/testsuite/gfortran.dg/char_transpose_1.f90:9:
internal compiler error: in gfc_conv_array_transpose, at
fortran/trans-array.c:726^M
Please submit a full
--- Comment #3 from mckinlay at redhat dot com 2006-04-20 21:45 ---
It does look like these should be made robust in the case of an EINTR which was
caused by a signal other than the interrupt signal.
As for ignoring ENOTCONN and ECONNRESET, I have a vague recollection that there
is a go
On powerpc64-unknown-linux-gnu with -m64, 85 tests in obj-c++.dg fail with:
elm3b11% /opt/gcc-nightly/trunk-20060420/bin/g++ -c -m64 basic.mm
basic.mm: In function void __objc_gnu_init():
basic.mm:21: internal compiler error: in rs6000_output_function_epilogue, at
config/rs6000/rs6000.c:15346
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-20 21:48 ---
*** Bug 27230 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-20 21:48 ---
*** This bug has been marked as a duplicate of 24955 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-20 21:50 ---
Let me reopen this for a second but really this is a dup of bug 24955 but maybe
there is a language type defined for objc++ and it is not yet implemented in
GCC.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from tromey at gcc dot gnu dot org 2006-04-20 22:16 ---
I see this with 4.2. 4.1 seems to work.
With jamvm and classpath cvs I see something else:
opsy. ~/workspace/classpath/install/bin/jamvm Sec
java.security.NoSuchAlgorithmException: DH
at java.security.KeyPairGen
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-20 22:16 ---
Created an attachment (id=11310)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11310&action=view)
updated test case
This is a version of the test case that compiles.
--
http://gcc.gnu.org/bugzilla/show_bug
Works in Sun's java. Doesn't work with gcj, with or without the trailing "/"
on the url.
gcj (GCC) 4.2.0 20060419 (experimental)
gcj -o Htest --main=Htest Htest.java
./Htest
Exception in thread "main" java.lang.StringIndexOutOfBoundsException
at java.lang.String.substring (libgcj.so.7)
at
--- Comment #3 from tromey at gcc dot gnu dot org 2006-04-20 23:08 ---
Ok... I fixed a problem with my jamvm setup and now
I am seeing this with classpath cvs as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
--- Comment #27 from pcarlini at suse dot de 2006-04-20 23:10 ---
(In reply to comment #23)
> Actually I don't see why the comma operator can be overridden in C++ (yes this
> I am raising a question about why the standards says it can).
Well, if we are talking about rationale and progra
--- Comment #7 from danglin at gcc dot gnu dot org 2006-04-20 23:12 ---
Ditto on hppa-unknown-linux-gnu.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-20 23:14 ---
Moving to Classpath.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Compone
--- Comment #9 from patchapp at dberlin dot org 2006-04-20 23:20 ---
Subject: Bug number PR20257
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-04/msg00785.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from janis at gcc dot gnu dot org 2006-04-20 23:31 ---
This test and obj-c++.dg/try-catch-9.mm get the same ICE on powerpc-linux on
trunk as of 2006-04-20, and have failed since I started including obj-c++ on
2005-11-02.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #4 from danglin at gcc dot gnu dot org 2006-04-20 23:37 ---
4649 else if (any_condjump_p (head))
4650gcc_assert (EDGE_COUNT (bb->succs) > 1
4651&& !BARRIER_P (NEXT_INSN (head)));
(gdb) p debug_r
--- Comment #3 from gerald at pfeifer dot com 2006-04-20 23:46 ---
(In reply to comment #2)
> Does Sparc-FreeBSD have working TLS support?
According to FreeBSD developers I asked, it does not, yet (probably due
to missing binutils support).
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-20 23:47 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Does Sparc-FreeBSD have working TLS support?
> According to FreeBSD developers I asked, it does not, yet (probably due
> to missing binutils support).
That mea
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-20 23:47 ---
*** Bug 27179 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from bryce at gcc dot gnu dot org 2006-04-20 23:48 ---
Subject: Bug 27170
Author: bryce
Date: Thu Apr 20 23:47:56 2006
New Revision: 113123
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113123
Log:
PR libgcj/27170
* gnu/gcj/runtime/natSharedLibLoa
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-20 23:48 ---
This also effects sparc64-portbld-freebsd6.1 as described in PR 27179.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
1 - 100 of 132 matches
Mail list logo
