--- Additional Comments From irar at il dot ibm dot com 2005-05-24 07:01
---
Thanks for fixing the patch.
I can't reproduce vect-106.c failure on i686-pc-linux-gnu. Could you please
give me some information?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
When dumping the trees during compilation GCC-4.1-2005010[1,8] went into
an endless loop during the *.c.t22.copyprop or the *.c.t37.copyprop2 dump, thus
generating larger and larger files. After the file reaches 2GB in size gcc
stops.
The same happens with gcc-4.1-20050515 in the steps
if I understand the code flow in FileCmpCmd correctly,
the first loop will initialize n1 and n2 because e1 = e2 = 0,
and k1 k2 is always BSIZE.
Even if the read() will return an error, the last check
to return either TCL_ERROR or TCL_OK is not undefined.
This is from
--- Additional Comments From olh at suse dot de 2005-05-24 07:48 ---
Created an attachment (id=8957)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8957action=view)
/tmp/filecmp.i.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21733
Segfault on compilation of following source:
struct _matrix {
double lineardata[4 * 4];
double operator()(int row, int col = 0) {
return lineardata[col * 4 + row];
}
};
struct matrix : public _matrix {
typedef _matrix parent;
double operator()(int row, int col = 0)
{ return
libcpp/configure falls over on a Solaris 9 machine (not tested on
others)
[EMAIL PROTECTED] libcpp]1% uname -a
SunOS taskmaster 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Fire-V240
[EMAIL PROTECTED] libcpp]0%
Adding quotes to the appropriate line fixes the problem:
[EMAIL PROTECTED] libcpp]1%
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24
08:12 ---
Fixed by Ulrich's patch
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00950.html
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg01066.html
--
What|Removed |Added
--- Additional Comments From Ulrich dot Windl at rz dot uni-regensburg dot
de 2005-05-24 08:31 ---
Created an attachment (id=8958)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8958action=view)
Log file with revised source, disassemblies for both compilers
I've revised the source
--- Additional Comments From pcarlini at suse dot de 2005-05-24 08:38
---
Indeed, Benjamin, I also get this, and that't why probably the issue is not
serious as I was afraid it was. However, we are basically relying on inlining
to happen for this to work, and that's brittle (as Jonathan
--- Additional Comments From giovannibajo at libero dot it 2005-05-24
09:27 ---
Can you provide one preprocessed source of those many?
--
What|Removed |Added
Chris Webb [EMAIL PROTECTED] wrote:
libcpp/configure falls over on a Solaris 9 machine (not tested on
others)
Thanks for the report. This used to be PR bootstrap/21230 and has been already
fixed a few days ago, for both GCC 4.1.0 and GCC 4.0.1.
Whe i try to compile with a simple make obtain this error:
g++: Internal error: Terminated (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for istructions.
make: *** [kismet_server.o] Error 1
--
Summary: g++ internal error
Product:
Attempting to create a MessageFormat with a time element styled as medium
raises an exception. The error, in MessageFormat.setLocale(), happens because
DateFormat.DEFAULT has the same value as DateFormat.MEDIUM, and the code was
obviously written with the assumption that this is not the case.
--
--- Additional Comments From gbenson at redhat dot com 2005-05-24 10:01
---
Created an attachment (id=8959)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8959action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21736
--- Additional Comments From gbenson at redhat dot com 2005-05-24 10:02
---
Created an attachment (id=8960)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8960action=view)
Fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21736
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 11:53
---
I can reproduce this problem on powerpc-apple-darwin, even without the
options -maltivec -mabi-altivec (which means that no simd vectorization takes
place). What happens is that the scalar_evolution_info
--- Additional Comments From irar at il dot ibm dot com 2005-05-24 11:57
---
I committed the patch, since I am not able to reproduce vect-106.c failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-05-24 11:59 ---
Subject: Re: poisoned ggc memory used for -ftree-vectorize
Paolo, is the above solution ok with you? If so, I'll go ahead and prepare a
patch. Alternatively, if ggc_collect is really required
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 12:54
---
Is there a rule that ggc_collect should not be called during loop
optimizations?
I don't know. (Zdenek?)
I think passes within the loop optimizer can assume that the scev information
cached in the scev
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-24
13:36 ---
Patch for 3.4.x: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
13:39 ---
Can you provide the preprocessed source?
--
What|Removed |Added
CC|
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-24
13:46 ---
scev_info_str should be ggc_alloc-ed.
Then, the hash table with the cache should be marked with GTY((param_is (struct
scev_info_str)))
If this fixes the bug, you can remove the TODO_ggc_collect from
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24
14:07 ---
Confirmed.
Reduced testcase (-O2 -ftree-vectorize -march=pentium4):
=
struct A
{
int a[4];
int operator[](int i) { return a[i]; }
};
struct B
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24
14:20 ---
Looks like it to me too, and I easily could have fallen into the same hole
twice
because it comes from a use of a shared library.
Does a single fix make both go away?
One never knows for sure until
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24
14:20 ---
*** Bug 21670 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
14:21 ---
Here is a C testcase:
struct a
{
int aa[4];
};
struct b
{
struct a aa;
};
void foo(struct b *bb)
{
int i;
for (i=0; i4; ++i)
{
struct a *aa = bb-aa;
struct a *aa1 = aa;
struct
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-24 14:24 ---
Subject: Re: poisoned ggc memory used for -ftree-vectorize
Is there a rule that ggc_collect should not be called during loop
optimizations?
I don't know. (Zdenek?)
there are
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-05-24 14:26 ---
Subject: Re: poisoned ggc memory used for -ftree-vectorize
there are several places in loop opts that are not GGC-safe (in
particular the tree nodes refered from loop structures are not
seen by
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
14:29 ---
This is not a regression, oh and this is much harder to get right which is why
this is a may/might
warning.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
14:35 ---
This is invalid code, the a after the declaration of the namespace is ambiguous.
Confirmed, this is only diagnostic problem.
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24
14:46 ---
Even shorter testcase:
templateint struct A;
struct B
{
templateint N void foo()
{
AN::X::Y;
}
};
--
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-05-24 15:06 ---
Subject: Re: poisoned ggc memory used for -ftree-vectorize
there are several places in loop opts that are not GGC-safe (in
particular the tree nodes refered from loop structures are
--- Additional Comments From dorit at il dot ibm dot com 2005-05-24 15:16
---
(In reply to comment #7)
So at the moment, you cannot run ggc_collect inside loop opts.
Is this going to change?
If not, I guess removing TODO_ggc_collect is the simpliest thing to do.
But
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-24
15:45 ---
Regression tested with a updated copy of gcc 4.1 CVS and with patch. Test
summary is available at
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01563.html.
The test failure is gone!
The problem has
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
15:47 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
15:57 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
Starting from file 20040208-2.c provided in the gcc testsuite I've obtained an
equivalent version performing an abort.
By changing the following two lines:
Internal = x_0 * 0x0.8000p+2L;
x = Internal;
in
x = x_0 *
--- Additional Comments From ferrandi at elet dot polimi dot it 2005-05-24
16:13 ---
Created an attachment (id=8961)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8961action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21737
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
16:18 ---
4.0.0 and 4.1.0 works for me on i686-pc-linux-gnu.
3.4.0 fails though.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
16:27 ---
Fixed.
--
What|Removed |Added
Status|WAITING |RESOLVED
--- Additional Comments From ferrandi at elet dot polimi dot it 2005-05-24
16:31 ---
Created an attachment (id=8962)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8962action=view)
i386 assembler of 20040208-2.c.t12.eh.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21737
MIPS does not yet have relaxation support in binutils. Instead, in line with
MIPS's own compiler, there is support for small data/bss sections, with
appropriate shorter relocations. What size of data goes in those sections is
determined with the MIPS target specific command line option -G.
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-24
16:53 ---
Nathan, this appeared with your binfo work last summer:
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00902.html
http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00663.html
Could you please have a look?
--
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-24
17:17 ---
I'm handling this.
Thanks for the test case; looks like there is already one in mauve,
but I'll verify that first.
--
What|Removed |Added
AIX 5.2.0 IBM pSeries 9117.570 (Power5 arch)
ML 5200-04
AIX 5XL does not have a libm.a installed by default. I do not have the
package to install it.
Attempting to build gcc-344
./configure --prefix=/usr/local --enable-shared --enable-threads=aix --enable-
aix64 --disable-nls
--- Additional Comments From nathan at gcc dot gnu dot org 2005-05-24
17:46 ---
ok
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot
hi, the following code compiled properly in 3.3.5:
#begin code
/* bind 2nd parameter in a 2 parameters metafunction */
template templatetypename A, typename B class MetaFunc, typename B
struct bind_2 {
templatetypename T
struct bound {
typedef typename MetaFuncT,B::type type;
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-24
18:04 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02298.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
18:10 ---
Confirmed, here is a reduced testcase (which is not accepted in 3.3.3 though):
template templatetypename A class MetaFunc struct bind_2;
templatetypename A struct Fx
{
typedef typename bind_2Fx::template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
18:15 ---
Confirmed, here is some analysis from RTH on IRC:
[16:54] rth we hashed a plt entry.
[16:54] rth grrr.
[17:30] tromey ah
[17:30] tromey I'm glad you debugged this then
[17:32] rth so the problem is
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-24
18:16 ---
Subject: Bug 21736
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-24 18:16:11
Modified files:
libjava:
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-24
18:17 ---
I've checked this in to the 4.0 branch and Classpath.
I'm leaving the PR open for now; I will check this in and close it
once the trunk is out of its slushy state.
Thanks for the patch and test case.
--
--- Additional Comments From giovannibajo at libero dot it 2005-05-24
18:28 ---
Invalid, use ::Fx.
Read http://gcc.gnu.org/gcc-3.4/changes.html
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-24
19:06 ---
Subject: Bug 21645
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-24 19:06:20
Modified files:
gcc/cp : ChangeLog optimize.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
19:06 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
We need a configure option to set java.library.path.
Right now libgcjawt.so in installed in ${prefix}/lib.
In FC4 we use java-gcj-compat to create a libjawt.so symlink in
/usr/lib/jvm/jre/lib/i386 (via alternatives).Programs running
System.loadLibrary(jawt) should find this without users
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
19:52 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-24
20:02 ---
Well no, the standard does not specify how unformatted sequential record markers
are implemented. In short, gfortran uses markers of type off_t, which is 64 bits
on operating systems with large file (LFS)
--- Additional Comments From bangerth at dealii dot org 2005-05-24 20:33
---
This is a duplicate of a dozen other bugs where gcc reports that there is
no declaration even though there are ambiguous ones. Can someone please go
through the list of open PRs and find it? We get a similar
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 20:36
---
This patch looks fine to me. I suggest just posting this, with a ChangeLog
entry, to gcc-patches.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530
--- Additional Comments From guptan at hotmail dot com 2005-05-24 20:39
---
Andrew,
I was able to strip the worksround mentioned in
http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00482.html and apply the patch at PR
target/13674 to avoid this bug.
If its of interest, I can post a patch for
--- Additional Comments From ian at airs dot com 2005-05-24 20:43 ---
I believe these are all now fixed in the CVS repository. Let me know if I
missed any.
--
What|Removed |Added
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 20:48
---
Kelley, any chance you can take a look at this? This is most probably related to
the (welcome) changes you did around this time.
-benjamin
--
What|Removed |Added
Generated tests t154 and t199 from gcc.dg/compat/struct-layout-1 fail
with an ICE compiling c_compat_y_tst.o with -m64 on powerpc64-linux.
The first started failing on 20050424, the second on 20050501, and both
have failed regularly since then, but it seems to be a latent bug
because results for
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-24 20:55
---
Created an attachment (id=8963)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8963action=view)
Minimized test case for struct-layout-1 test t154.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21742
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-24 20:56
---
Created an attachment (id=8964)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8964action=view)
Minimized test case for struct-layout-1 t199
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21742
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
URL|
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
21:26 ---
(In reply to comment #4)
as a note: UNPACK also has issues with as scalar mask, maybe also with memory
allocation
I have just submitted a patch for the memory allocation issue.
A scalar mask for unpack
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
21:55 ---
This has been fixed on mainline, still outstanding in 4.0
--
What|Removed |Added
Known
This builtin, that would be *so* useful in the implementation of std::complex
cannot be enabled at the moment due to this issue (see also builtins.def):
http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00510.html
We should *really* find a way to work around the problem!
(not sure whether the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
22:04 ---
All three are now done by PR 15459.
--
What|Removed |Added
AssignedTo|unassigned at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
22:07 ---
We could just define the __builtin_ version of the function.
I keep on wondering if (and when) C++ gets the C99 complex functions and types,
what would they do
about complex log.
Confirmed.
--
--- Additional Comments From pcarlini at suse dot de 2005-05-24 22:14
---
We could just define the __builtin_ version of the function.
I don't understand, can you explain? In my understanding everything is in place,
indeed all the other builtins are there, *only* we cannot do that for
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-24
22:20 ---
If you uncomment what is in builtins.def, you get both clog and __builtin_clog.
If we define it as DEF_LIB_BUILTIN instead of DEF_C99_BUILTIN, we only get
__builtin_clog.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-24
22:22 ---
Subject: Bug 18495
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-24 22:22:10
Modified files:
libgfortran:
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
22:23 ---
The fix in 4.0 was incomplete, it is complete now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-24
22:40 ---
For 4-byte complex, an option is to check the alignment at runtime.
If the complex is aligned on an 8-byte boundary, it should be
perfectly OK to call the 8-byte-integer routines.
The check could be done
--- Additional Comments From pcarlini at suse dot de 2005-05-24 22:46
---
Ah, ah, cool, thanks! I'm going to propose that!
--
What|Removed |Added
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-24 23:02
---
Diego, can this PR be closed as fixed?
Test gcc.dg/uninit-4.c started to XPASS with this patch from dnovillo:
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00529.html
On the same day, test uninit-9.c also
--- Additional Comments From dnovillo at redhat dot com 2005-05-24 23:06
---
Subject: Re: bogus uninitialized variable warning for powerpc64
On Tue, May 24, 2005 at 11:02:09PM -, janis at gcc dot gnu dot org wrote:
Diego, can this PR be closed as fixed?
Yes. Apologies for not
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-24
23:42 ---
Subject: Bug 19833
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-24 23:41:53
Modified files:
gcc/testsuite/gcc.dg: uninit-4.c uninit-9.c
--- Additional Comments From stevenj at alum dot mit dot edu 2005-05-24
23:51 ---
I doubt that merely omitting close() from the end of the library will entirely
fix the problem. You really need to add an fflush before every output to stdio.
For example, modify ciotst.f to:
Trying to build m6812 cross compiler causes an internal compiler error.
Configured with ../../
gcc-4.0.0/configure --prefix=/usr/cross/m6812 --target=m6812 (using the
gcc-core-4.0.0, using
only the c compiler). Re-running the command that failed with a -v causes the
following error..
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-25
00:23 ---
*** This bug has been marked as a duplicate of 19960 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-25
00:23 ---
*** Bug 21744 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From ian at airs dot com 2005-05-25 00:33 ---
Just a note that this still fails to issue an error on mainline.
--
What|Removed |Added
Last
--- Additional Comments From kcook at gcc dot gnu dot org 2005-05-25 01:11
---
/home/hp/cvs_areas/combined/combined/libstdc++-v3/configure: line 1545:
GCC_NO_EXECUTABLES: command not found
This was due to my changes.
This error was simply due to a mismatch in aclocal versions back
While building a cross-compiler on my Linux x86 box, I got this error in the
middle of the libstdc++ build:
Command:
/usr/local/src/build-gcc/gcc/xgcc -shared-libgcc -B/usr/local/src/build-gcc/gcc/
-nostdinc++ -L/usr/local/src/build-gcc/h8300-hms/h8300s/normal/libstdc++-v3/src
--
What|Removed |Added
CC||aarestad at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21745
--
What|Removed |Added
Component|libstdc++ |target
Keywords||build, ice-on-valid-code
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From fitzsim at redhat dot com 2005-05-25 01:59
---
Fixed by Sven de Marothy in GNU Classpath.
--
What|Removed |Added
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From fitzsim at redhat dot com 2005-05-25 02:01
---
Are you using focus-follows-mouse? If so, this is a known problem; a change in
a window's active state causes an expose event on the entire window, which
triggers a repaint. We need to find a way to prevent
--- Additional Comments From fitzsim at redhat dot com 2005-05-25 02:03
---
Do you still see this on HEAD? I can't reproduce it. What applet are you
running?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21649
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
Consider the code:
class A {
public:
virtual void foo() = 0;
};
class B : public A {
public:
virtual void foo() {}
};
int main()
{
const A a = B(); // -- here
return 0;
}
in g++-4.0, as it comes pre-installed on Mac 10.4, I get the error:
$ g++ -c g++4-bug.cc
The native code in the lwjgl distribution refers to an int depth field in
JAWT_X11DrawingSurfaceInfo. We don't have that in our version.
This code won't build without it.
--
Summary: JAWT_X11DrawingSurfaceInfo missing depth field
Product: gcc
Version: 4.0.1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-25
02:35 ---
This is not a bug in the FSF released GCC, only Apple's report it to them.
--
What|Removed |Added
--
What|Removed |Added
Component|libgcj |AWT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21747
1 - 100 of 101 matches
Mail list logo
