Details in this thread:
http://gcc.gnu.org/ml/gcc/2006-09/msg00167.html
"
A silly little testcase which the vectorizer doesn't vectorize:
unsigned char qa[128];
unsigned char qb[128];
unsigned char qc[128];
unsigned char qd[128];
void autovectqi (void)
{
int i;
for (i = 0; i
--- Comment #9 from acahalan at gmail dot com 2006-09-21 06:18 ---
Regarding comment #3, why is -fwhole-program accepted without -ffreestanding?
Unlike the original poster (who wrote "I don't care about this anymore."),
this is a rather annoying bug for me. I'll check again tomorrow, bu
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-21 06:05 ---
Actually this is a dup of bug 17402.
-fwhole-program causes memcpy/memset to become static.
*** This bug has been marked as a duplicate of 17402 ***
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-21 06:05 ---
*** Bug 29159 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-09-21 06:03 ---
related to PR 24729 and another PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29159
I have a number of *.c files, including a bit of inline assembly, which form
the entire program. ("program" being a shared object which gets executed via
the _init function) There are no other source libraries. I have a memcpy.c and
a memset.c, both containing the obvious functions. This is based o
--- Comment #4 from acahalan at gmail dot com 2006-09-21 05:12 ---
Target powerpc-*-* is wrong. See bug 29158 (my dupe) for the i386 assembly
produced by a slightly more recent compiler. It's x86_64 too.
It's not just (char*) either. It's (short*) and even struct members.
--
http:/
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-09-21 04:53
---
The last patch (on i686), cut the stack space from 11k to 5k. Maybe there is
more still.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 04:39 ---
*** This bug has been marked as a duplicate of 23684 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-21 04:39 ---
*** Bug 29158 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29158
In the example below, define T as "char" or "short". (probably "int" too on a
64-bit machine, with minor adjustment to the example code) Compile the code
with "-Os -S" and observe the assembly. Even if there are no aliasing or
alignment issues, the compiler fails to merge multiple stores into large
--- Comment #4 from belandor at web dot de 2006-09-21 04:33 ---
okay, aparently something had set the environment options
ADA_INCLUDE_PATH and
ADA_OBJECT_PATH
to the additional paths. That would explain, why stuff went haywire. Is there
any place to document this? - Maybe someone else
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-21 04:23 ---
may_alias_p returns true
for:
(gdb) p debug_generic_expr (ptr)
xaD.1527
(gdb) p debug_generic_expr (var)
SMT.5D.1548
(In reply to comment #2)
> So, actually, i'm pretty sure they should have the same SMT, because t
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2006-09-21
04:16 ---
Okay, the autoconf changes for libstdc++ and libgcj actually work okay.
The test program uses the static libgcc.a to link (which lacks the
__Unwind_GetIP symbol) so that HAVE_GETIPINFO remains unde
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-21 04:06 ---
Note in 4.1.2, we have two different TMT's here for the variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
--- Comment #3 from belandor at web dot de 2006-09-21 03:59 ---
my configure line:
CC="gcc" /home/ap/colibri/buildroot/toolchain_build_arm/gcc-4.1.1/configure \
--prefix=/home/ap/colibri/buildroot/build_arm/staging_dir \
--build=i386-pc-linux-gnu \
--host=i386-pc-linux-gnu \
--target=ar
--- Comment #2 from belandor at web dot de 2006-09-21 03:57 ---
it seems, that my RTS_DIR variable is wrong.
the Makefile ($BUILDDIR/gnattools/Makefile) extracts or adapts the directory
using
RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib )))
right before the rule for gna
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-21 03:42 ---
So how did you configure GCC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29157
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29157
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-09-21 03:37
---
Actually note here is one for 32bit targets also:
void foo( unsigned long long bb, unsigned short tn, unsigned e, unsigned* w );
void foo( unsigned long long bb, unsigned short tn, unsigned e, unsigned* w )
{
I'm trying to build a cross-ada compiler (using different toolchains) with
gcc-4.1.1 or gcc-4.2.0-20060919.
In both cases, when building the last stage, the make process fails building
gnattools (i.e. gnattools-cross).
Error message:
make -C ../gcc/ada/tools -f ../Makefile \
"CC=gcc" "CFLAGS=-g
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-21 03:31
---
Confirmed with the testcase in comment #10.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29138
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-09-21 02:32 ---
So, actually, i'm pretty sure they should have the same SMT, because they
should be in the same alias set.
Why do they get different SMT's?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
--- Comment #10 from jblaine at mitre dot org 2006-09-21 02:24 ---
Subject: Re: New: Found a problem with the JNI methods declared
and implemented
Found this thread in the bug mailing list archives.
I have the same problem :(
Is there a fix more specific than "disable that test" so
--- Comment #14 from sayle at gcc dot gnu dot org 2006-09-21 02:13 ---
Subject: Bug 26983
Author: sayle
Date: Thu Sep 21 02:13:48 2006
New Revision: 117106
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117106
Log:
2006-09-20 Steven Bosscher <[EMAIL PROTECTED]>
PR mid
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29128
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29119
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-09-21 02:03
---
PA-RISC GNU/Linux is not a primary platform, so I've marked this P5. However,
PA-RISC HP-UX is a primary platform, so if this bug manifests there, please set
this back to P3 with an explanatory comment.
--
mmi
--- Comment #7 from pinskia at physics dot uc dot edu 2006-09-21 01:06
---
Subject: Re: testcase gcc.dg/20020103-1.c fails with "scan-assembler-not LC"
>
>
>
> --- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-09-20
> 23:49 ---
> Does anyone know why we don
>
>
>
> --- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-09-20
> 23:49 ---
> Does anyone know why we don't run this test at lp64 on powerpc? I find that on
> powerpc-apple-darwin8 the following changes allow...
>
> make check-gcc RUNTESTFLAGS="--target_board=unix'{-m32
--- Comment #12 from pcarlini at suse dot de 2006-09-21 00:13 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from paolo at gcc dot gnu dot org 2006-09-21 00:12 ---
Subject: Bug 29134
Author: paolo
Date: Thu Sep 21 00:11:52 2006
New Revision: 117099
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117099
Log:
2006-09-20 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-09-20
23:49 ---
Does anyone know why we don't run this test at lp64 on powerpc? I find that on
powerpc-apple-darwin8 the following changes allow...
make check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
dg.exp=2002
--- Comment #2 from djg at cray dot com 2006-09-20 23:49 ---
The definition of restrict in C99 6.7.3.1 doesn't say that only the original
restrict-qualified pointer can be used to access the object it points to; it
says that any pointer "based on" the original restrict-qualified pointer
--- Comment #11 from dannysmith at users dot sourceforge dot net
2006-09-20 23:37 ---
Fixed on trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
---
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-20
23:33 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
> Huh. Dave, is revision 116942M the same as revision 116942?
I applied r116954 to 116942.
> Of these, 19_diagnostics/
--- Comment #10 from dannysmith at gcc dot gnu dot org 2006-09-20 23:32
---
Subject: Bug 27650
Author: dannysmith
Date: Wed Sep 20 23:32:07 2006
New Revision: 117097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117097
Log:
PR target/27650
* g++.dg/ext/dllimpor
--- Comment #10 from pluto at agmk dot net 2006-09-20 23:31 ---
i have a reduced testcase:
$ cat tmp.c
void foo( unsigned long bb, unsigned short tn, unsigned e, unsigned* w )
{
unsigned n = tn + bb;
do {
e = (e > n) ? e : *w;
n -= (e > n)
--- Comment #9 from dannysmith at gcc dot gnu dot org 2006-09-20 23:27
---
Subject: Bug 27650
Author: dannysmith
Date: Wed Sep 20 23:27:05 2006
New Revision: 117096
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117096
Log:
PR target/27650
* class.c (check_for_o
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-09-20 22:55 ---
IIRC my change can cause entries to be present into the hash table that
wouldn't have been there before. However this should be harmless. I don't have
any helpful suggestons why this is broken.
--
http://gcc.gnu
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29105
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-09-20 22:49
---
The language linkage of the type is supposed to matter in some cases -- but G++
doesn't implement that, so I don't think the difference is observable in GNU
C++. In any case, we should try to make the file compile
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29092
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29091
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29080
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29048
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29039
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29021
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29020
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-09-20 22:32
---
A meta-bug would be helpful.
I've marked this P2, since this bug doesn't actually result in a
user-observable problem on a single host -- but it is extremely desirable from
the point of view of us, as GCC develope
--- Comment #4 from abs at absd dot org 2006-09-20 22:27 ---
Seeing the same issue with gcc 3.4.6 on NetBSD/i386 4.0_BETA using gmake 3.81
and SHELL=/bin/tcsh
--
abs at absd dot org changed:
What|Removed |Added
-
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 22:26 ---
Confirmed, a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-09-20 22:26
---
Marked as P5 because this is marked as applying to Alpha/OSF. If this problem
applies to other platforms, please set back to P3 with explanatory comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||alias
Known to fail||4.2.0
Kno
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28211
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
The testcase below gets misscompiled at -O2.
The alias info looks this way:
Dereferenced pointers
xa, UID 1527, struct test1 *, symbol memory tag: SMT.4, default def: xa_4
xb, UID 1528, struct test2 *, symbol memory tag: SMT.5, default def: xb_3
Symbol memory tags
SMT.4, UID 1547, struct test1
--- Comment #6 from steven at gcc dot gnu dot org 2006-09-20 22:19 ---
*** Bug 28405 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-20 22:19 ---
*** This bug has been marked as a duplicate of 24929 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-20 22:05 ---
The bug database is no place for this kind of question. First you should look
for answers in the source code. This will be trial and error, but this is your
exercise so don't ask us to make it for you. If you get s
--- Comment #2 from lopezibanez at gmail dot com 2006-09-20 22:04 ---
I can confirm this in a recent build of GCC: (GNU) 4.2.0 20060913
(experimental) on i686-pc-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28405
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
Dear Readers,
Although this is not a bug report I tought I better to ask
my problem in here and ask you if you can help me.
I have to add some user defined procedures or types to C and to alter GCC
to detect these changes, actually I want to alter the C language
definition which is given to GCC. fo
--- Comment #6 from laurent at guerby dot net 2006-09-20 21:51 ---
Fixed on 4.2
--
laurent at guerby dot net changed:
What|Removed |Added
Status|NEW
--- Comment #7 from sje at cup dot hp dot com 2006-09-20 21:23 ---
This bug is weird. If I remove the code in cse_insn where the dest_addr_elt
field is used, I still get the bug. So the problem occurs when creating the
dest_addr_elt data, not when using it. This makes no sense to me,
--- Comment #5 from guerby at gcc dot gnu dot org 2006-09-20 20:46 ---
Subject: Bug 28716
Author: guerby
Date: Wed Sep 20 20:46:28 2006
New Revision: 117092
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117092
Log:
2006-08-20 Laurent GUERBY <[EMAIL PROTECTED]>
PR ada
--- Comment #9 from pluto at agmk dot net 2006-09-20 20:44 ---
Created an attachment (id=12302)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12302&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
--- Comment #8 from pluto at agmk dot net 2006-09-20 20:44 ---
(In reply to comment #7)
> and one more misscompiled program -> gzip-1.3.5.
> this time 4.1.2 with -O2 -fwrapv produces wrong code.
>
> $ dd if=/dev/zero of=foo count=10
> $ gzip foo
> $ gzip -d foo.gz
> $ gzip: foo.gz: inva
--- Comment #8 from tromey at gcc dot gnu dot org 2006-09-20 19:15 ---
ok, I'm closing.
Please reopen if it is still a problem.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #22 from jconner at gcc dot gnu dot org 2006-09-20 18:57
---
Subject: Bug 25505
Author: jconner
Date: Wed Sep 20 18:57:46 2006
New Revision: 117091
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117091
Log:
2006-09-20 Josh Conner <[EMAIL PROTECTED]>
PR mi
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 18:47 ---
**pDest = *pSource++;
*( *pDest++ )++;
[t1.c : 1055] D.1948 = *pWriteBuf;
[t1.c : 1055] D.1949 = *pReadBuf;
[t1.c : 1055] *D.1948 = D.1949;
[t1.c : 1055] pReadBuf = pReadBuf + 1B;
[t1.c : 1056] D.1950
--- Comment #7 from sgilbertson at gcc dot gnu dot org 2006-09-20 18:45
---
I checked out revision 117082 (trunk) and successfully built a few static
binaries with it. So unless Thomas saw a different problem than I did, I'd say
it's fixed.
Configured with: ../gcc/configure --prefix=/
Overview:
The following C generates bad assembler on both PowerPC and Intel, even with no
optimization:
*( *pDest++ )++ = *pSource++;
Ripping this apart into two lines succeeds, thus:
**pDest = *pSource++;
*( *pDest++ )++;
System Description:
System: Apple OS X 10.4 (gcc 4.0.1) and Mand
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:42
---
Thanks for the fix.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:39
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:38
---
> Yes, this is a regression.
> It works fine with -O2 with my system compiler (FC5 gcc, based on gcc 4.1).
> It also works fine with -O2 using my gcc 4.1 build.
> It fails with svn head.
Thanks for the info.
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152
--- Comment #7 from pinskia at physics dot uc dot edu 2006-09-20 17:16
---
Subject: Re: [4.1/4.2 regression] ICE in extract_insn,
at recog.c:2084 (unrecognizable insn) [arm]
On Wed, 2006-09-20 at 16:38 +, bugreports at nn7 dot de wrote:
>
> --- Comment #6 from bugrepo
On Wed, 2006-09-20 at 16:38 +, bugreports at nn7 dot de wrote:
>
> --- Comment #6 from bugreports at nn7 dot de 2006-09-20 16:38 ---
> I am getting exactly the same here on ppc (so it is not just arm specific):
Yes it is. The bug you are getting with PPC is a different bug and
shoul
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-20 17:04 ---
Yes, I plan on making an ecj jar download available.
In the near term I will put one on gcc.gnu.org (or elsewhere).
In the longer term I plan to get my ecj changes upstream, and then
we will be able to point people at
--- Comment #16 from tromey at gcc dot gnu dot org 2006-09-20 16:57 ---
Yes, this is a regression.
It works fine with -O2 with my system compiler (FC5 gcc, based on gcc 4.1).
It also works fine with -O2 using my gcc 4.1 build.
It fails with svn head.
--
http://gcc.gnu.org/bugzilla/s
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
The new Unsafe code assumes pthreads in a number of places.
This blocks a merge.
--
Summary: [ecj] clean up pthread assumptions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgc
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-20 16:53 ---
This will be fixed by the ecj merge; we're deleting this version of gcjh.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from sje at cup dot hp dot com 2006-09-20 16:49 ---
Fix is now checked in.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|NE
--- Comment #1 from mtrudel at gmx dot ch 2006-09-20 16:49 ---
Tom commented this on the mailing list. Might be useful:
Offhand I would expect this to work ok. You might verify that USE_LTDL is set
on Windows; see the two definitions of _Jv_SetDLLSearchPath in
natSystemProperties.cc.
1 - 100 of 139 matches
Mail list logo
