--- Additional Comments From jvdelisle at verizon dot net 2005-02-01 07:52
---
Using -O3 with flag_complex_divide_method = 1 in toplev.c on i686-pc-linux-gnu
CGV drivers: 64 out of 1092 tests failed to pass the threshold
CST drivers: 1 out of 11664 tests failed to pass t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
07:04 ---
Subject: Bug 19499
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-02-01 07:04:01
Modified files:
gcc/testsuite : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
07:04 ---
Subject: Bug 19366
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-02-01 07:04:01
Modified files:
gcc/testsuite : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
07:04 ---
Subject: Bug 18757
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-02-01 07:04:01
Modified files:
gcc/testsuite : Change
For floating-point (float/double) class
members that are initialised, gcjh generates invalid
C++ code.
See:
http://gcc.gnu.org/ml/gcc/2005-01/msg01738.html
for the issue in general and:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00032.html
for how it affects GCJ.
--
Summary:
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-01 06:36
---
Subject: Re: [4.0 Regression] A side effect is missed in 0 % a++.
On Mon, Jan 31, 2005 at 08:45:34PM -0700, Jeffrey A Law wrote:
> + /* X % 0, return X % 0 unchanged so that we can get the
> + prope
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
05:57 ---
Hmm, maybe gcc should be able to optimize the following RTL better when
combining them (if gcc
does combine them):
(insn 19 18 20 0 (set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (subreg:DI
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
05:56 ---
Subject: Bug 19499
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-01 05:56:08
Modified files:
gcc/testsuite : ChangeLog
gcc/cp : C
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
05:56 ---
Subject: Bug 18757
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-01 05:56:08
Modified files:
gcc/testsuite : ChangeLog
gcc/cp : C
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
05:56 ---
Subject: Bug 19366
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-01 05:56:08
Modified files:
gcc/testsuite : ChangeLog
gcc/cp : C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
04:43 ---
*** Bug 19737 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
04:43 ---
This is a kinda of a regression but GDR says there are problems with core issue
224 still, this is a dup
of bug 9634.
Note DR numbers are in summary for most bugs as a quick search of that DR
number would
--- Additional Comments From gianni at mariani dot ws 2005-02-01 04:41
---
BTW - gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) accepts the code, would
this be a regression ?
--
What|Removed |Added
-
In a recent posting by Daveed Vandervoorde on comp.std.c++, apparently the code
below is valid, yet the latest GCC snapshot (20050130) indicates that this is
still an issue.
struct N {
typedef char C;
};
template struct B {
typedef long L;
};
template struct S: N, B {
typedef int I;
S::I i; //
--- Additional Comments From echristo at redhat dot com 2005-02-01 04:25
---
[EMAIL PROTECTED] ~/tmp]$ /dzur/sourceware/builds-gcc/build-dzur/gcc/xgcc
-B/dzur/sourceware/builds-gcc/build-dzur/gcc/ bug.c -c -save-temps -g3
*** glibc detected *** malloc(): memory corruption: 0x08ca4ba8 ***
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
04:06 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From law at redhat dot com 2005-02-01 03:46 ---
Fixed with tonight's change to fold-const.c
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From echristo at redhat dot com 2005-02-01 03:06
---
Deprecating -mint64.
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00019.html
--
What|Removed |Added
-
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
02:37 ---
Subject: Bug 9157
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-01 02:36:36
Modified files:
gcc/java : ChangeLog parse.y
Log message:
--- Additional Comments From echristo at redhat dot com 2005-02-01 02:21
---
The best I can get without major surgery to cpp is this:
#include "test.h"
/* comment from include line */
Which is likely insufficient for any good needs. I think what we need to be able
--- Additional Comments From janis at gcc dot gnu dot org 2005-02-01 01:51
---
I just tried with today's mainline for powerpc64-unknown-linux-gnu and get the
same two ICEs as were reported originally. The 3.4 branch gives the error that
Serge noted for -DVECSIZE=2 and accepts -DVECSIZE=
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-01
01:32 ---
Fixed om PA. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19696
--- Additional Comments From law at redhat dot com 2005-02-01 01:04 ---
This testcase (from Ranjit) should give an error on the bogus case label:
int foo(int x)
{
switch(x)
{
case 0 % 0:
return 1;
default:
return 2;
}
}
I'm testing a fix for both problems.
--
http:
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
Today's GCC mainline ICEs building 176.gcc from SPEC CPU2000 on
powerpc64-unknown-linux-gnu with "-O1 -g" and either -m32 or -m64:
sdbout.c:1026: error: Type mismatch between an SSA_NAME and its symbol.
sdbout.c:1026:
--- Additional Comments From joel at oarcorp dot com 2005-02-01 00:46
---
Subject: Re: gnat tools not buildable cross
charlet at adacore dot com wrote:
> --- Additional Comments From charlet at adacore dot com 2005-01-31 16:38
> ---
> Subject: Re: gnat tools not buildable cr
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
00:45 ---
No the grammar in this example is correct even though it looks werid for a non
native speaker of
English.
--
What|Removed |Added
---
--
What|Removed |Added
Keywords||diagnostic
Summary|Spelling "error" in error |Grammar "error" in error
|message
When fed with the following code:
unsigned char val = -1;
gcc-4.0.0 20050130 (experimental) reports:
warning: converting of negative value '-0x1' to 'unsigned char'
As for my feeling, it should correctly say "conversion of..." or "converting"
but not "converting of...".
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
00:37 ---
This is no longer a regression as we don't ICE on it but it is still a rejects
valid.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01
00:33 ---
Patch posted for review for inclusion in GCC 4.0 is here:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02207.html.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
00:32 ---
This changed between 20040708 and 20040709.
Which means that it was most likely caused by:
2004-07-08 Joseph S. Myers <[EMAIL PROTECTED]>
Neil Booth <[EMAIL PROTECTED]>
PR c/2511
--- Additional Comments From sje at cup dot hp dot com 2005-02-01 00:27
---
Resolving as fixed since 3.4 and ToT both look OK. It is still broken on the
3.3 branch.
--
What|Removed |Added
--
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01
00:23 ---
Let's just leave it as-is and revisit for 4.1.
--
What|Removed |Added
AssignedTo|ste
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01
00:22 ---
I have no further ideas for speedups for this bug...
--
What|Removed |Added
Assigned
--
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2004-09-02 11:05:08 |2005-02-01 00:21:16
date|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
00:20 ---
: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19708
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01
00:19 ---
I'm on there twice :)
--
What|Removed |Added
CC|stevenb at suse dot de
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01
00:15 ---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02245.html
--
What|Removed |Added
S
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
00:10 ---
I think this has been fixed on the mainline but I don't know for sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-01
00:09 ---
Subject: Bug 19333
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-01 00:09:40
Modified files:
gcc: ChangeLog c-decl.c c-typeck.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
00:03 ---
: Search converges between 2003-07-16-trunk (#296) and 2003-07-17-trunk (#297).
Confirmed.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
00:03 ---
: Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160).
Confirmed.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-01
00:01 ---
: Search converges between 2004-06-22-trunk (#470) and 2004-06-24-trunk (#471).
Confirmed.
--
What|Removed |Added
---
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 23:42
---
d-19680-1 + d-19680-3 isn't as good, 14.9fps, as some silly stack movements are
induced; ie:
40265f: 0f 29 04 24 movaps %xmm0,(%esp)
402663: 0f 57 c0xorps %xmm0,%xmm0
--- Additional Comments From drepper at redhat dot com 2005-01-31 23:34
---
> /* If this function requires more stack slots than the current
> function, we cannot change it into a sibling call. */
> || args_size.constant > current_function_args_size
>
> args_size.c
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 23:28
---
Wow! We got a winner. 15.8 fps with -fno-gcse, inlining and only d-19680-3.
402680: 66 0f 6f d1 movdqa %xmm1,%xmm2
..
402688: 66 0f db 50 30 pand 0x30(%eax),%xmm2
40268d:
The following invalid code snippet causes an ICE since gcc 3.4.0:
==
struct A;
void foo() { A::~A(); }
==
Mainline's error message reads:
bug.cc: In function 'void foo()':
bug.cc:2: internal compiler error: vector VEC(tree) index do
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-31
23:17 ---
FWIW we don't emit the tail call because of this:
/* If this function requires more stack slots than the current
function, we cannot change it into a sibling call. */
|| args_size.c
The following invalid code snippet causes an ICE since gcc 3.4.0:
==
struct A {};
void foo() { A().A::~~A(); }
==
Mainline's error message reads:
bug.cc: In function 'void foo()':
bug.cc:2: error: expected class-name before '~' toke
The following invalid code snippet is accepted by mainline:
==
struct A;
struct B { ~A(); };
==
Mark, this was caused by your patch
http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00888.html
This patch not only removed the error message
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 22:58
---
In previous test i've used a crufted string of compilation options; i've removed
all that crap for -O3 -march=k8 -mfpmath=sse -fno-gcse -fno-exceptions.
The second patch, hack sse simode inputs, is a small win or
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
22:46 ---
*** Bug 19731 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
22:46 ---
This is a dup of bug 18962 which is already fixed in 3.4.4 and 4.0.0.
*** This bug has been marked as a duplicate of 18962 ***
--
What|Removed |Added
---
--
What|Removed |Added
Keywords||accepts-invalid, rejects-
||valid
http://gcc.gnu.org/bugzilla/s
It looks like in the specialization of a static template member of a template
class, the argument names are used from the original declaration, rather than
from the specialization declaration.
template
struct W {
template static S getAsS(const T &v_orig);
};
template <>
template
inline S W::
ubl$8, %esp
movl$1, %ecx
movl$3, 4(%esp)
movl$2, (%esp)
callfoo
subl$8, %esp
addl$8, %esp
ret
.size bar, .-bar
.ident "GCC: (GNU) 4.0.0 20050131 (experimental)"
.section.no
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 22:21
---
Oops, my bad. Thought pshufd mixed both operands à la shufps; i'm obviously not
familiar with the integer side of SSE.
And yes the combination is a lose, albeit a small one around 3%. But i'm timing
the whole thin
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-01-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
22:12 ---
*** Bug 19730 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
22:12 ---
(In reply to comment #1)
> Ian, can you have a look? Mainline __cxa_demangle returns -2.
This is a dup of bug 16240 which both the mangling and demangling problems have
been fixed on the
mainline (4.0.0).
--- Additional Comments From yuri at tsoft dot com 2005-01-31 22:02 ---
actually I want to generalize it:
any situation in C++/C/Ada when many enough close (in memory) variables are
assigned the same value should use bulk "stos(b/w/l)". This should be applied as
part of optimization.
--
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-01-31
21:53 ---
FWIW, I've not had any problems like this, although I tend to use
the MIPSpro cc as the bootstrap compiler, not gcc 3.3. There have
been other successful build reports too.
If you don't have access to MIP
--- Additional Comments From law at redhat dot com 2005-01-31 21:35 ---
Subject: Re: [meta-bug] optimizations that CSE still
catches
On Mon, 2005-01-31 at 20:14 +, stevenb at suse dot de wrote:
> --- Additional Comments From stevenb at suse dot de 2005-01-31 20:14
> --
--- Additional Comments From pcarlini at suse dot de 2005-01-31 21:20
---
Ian, can you have a look? Mainline __cxa_demangle returns -2.
--
What|Removed |Added
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 21:12
---
(In reply to comment #21)
> 4010ce: 0f 29 6c 24 10 movaps %xmm5,0x10(%esp)
> 4010de: 0f 59 5c 24 10 mulps 0x10(%esp),%xmm3
> 4011a1: 0f 29 04 24 movaps %xmm
gcc version 3.4.2 [FreeBSD] 20040728
# c++filt _Z4test1AILZ2buEE
Segmentation fault (core dumped)
gcc version 3.2
# c++filt _Z4test1AILZ2buEE
test(A)
Quick workaround patch based on 3.2 libiberty sources.
(similar to be done over libiberty demangler)
Index: cp-demangle.c
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 21:02
---
(In reply to comment #22)
No, it isn't. Look at your functions again. The assembly that you
pasted is 100% perfect. You cannot improve on that in any way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Additional Comments From ovidr at users dot sourceforge dot net
2005-01-31 21:02 ---
Created an attachment (id=8118)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8118&action=view)
The file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19729
appRandom might be null in DSASignature (it is not initialized), yet in the
method "public byte[] engineSign()" appRandom is used which causes an NPE.
Casey Marshall sent me the attached replacement DSASignature.java file and it
works.
--
Summary: libgcj DSASignature.java null point
Index: Gnu.java
===
RCS file: /cvsroot/gcc/gcc/libjava/gnu/java/security/provider/Gnu.java,v
retrieving revision 1.7
diff -u -r1.7 Gnu.java
--- Gnu.java 15 Nov 2004 20:02:04 - 1.7
+++ Gnu.java 31 Jan 2005 20:47:01 -
@@ -129,
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:35
---
Hmm, there's something fishy with _mm_set1_epi32.
With your patches there's no stack copy anymore but, with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19714 testcase, i get:
00401080 :
401080: 66 0f 6e 4
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 20:28
---
(In reply to comment #5)
> Isn't this the same as PR 16925?
No, this is different. The patch attached to PR 16925 fixes the problem on all
three hosts (amd64, ia64 and alpha). And the problem is on a different
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
20:22 ---
Isn't this the same as PR 16925?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
--- Additional Comments From tbptbp at gmail dot com 2005-01-31 20:18
---
-fno-gcse is a godsend, instant speedup and most of the sillyness when inlining
is gone.
Now i've applied both your patches, and while there's promising they also
triggers their own nastyness; gcc is so fond of me
--- Additional Comments From stevenb at suse dot de 2005-01-31 20:14
---
Subject: Re: [meta-bug] optimizations that CSE still catches
My numbers for not disabling CSE completely but disabling path following
are a lot less pessimistic. This was on an AMD Opteron at 1600MHz:
GCC was co
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 19:59
---
I have just built a new gcc targeted for m68hc11 with gcc-3.4, and the problem
is still there, both with default optimizations and with -O2.
I have also run 'gcc -da' on the testcase on both amd64 and ia64 hos
--- Additional Comments From aurelien at aurel32 dot net 2005-01-31 19:56
---
Created an attachment (id=8117)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8117&action=view)
diff of debugging dumps between amd64 and ia64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
--- Additional Comments From bangerth at dealii dot org 2005-01-31 19:30
---
In general, you have to make sure that you have the required versions
of other packages. As for helping you to sort out hardware problems --
please look elsewhere on the web, this forum here is concerned with
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-31 19:04
---
I think you'll also want to try using -fno-gcse. The gcse pass is hoisting
values out of your loop (as it is supposed to), except that we don't have
enough registers to hold it all, so the values get spilled
--- Additional Comments From sitaram dot banda at gmail dot com 2005-01-31
19:01 ---
(In reply to comment #5)
> I think it is time to check your memory and/or hardware, this works for so
many other people.
Yeah, can you help me insorting out the issue. I am providing some of the info
--- Additional Comments From pcarlini at suse dot de 2005-01-31 18:57
---
Adding pragma visibility push(default)/pop to the basic_string.h header (or to
the std_string.h header, for that matter) does *not* fix the issue for me. Is
anyone able to confirm this or viceversa? (binutils 2.15.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
18:49 ---
Confirmed, note this is either a front-end bug because the front-end produces
multiple stores or a
target bug for not combining those stores to one store string instruction.
Also if one initializer is mis
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 18:44
---
And PR18360 indeed related to this bug report.
If gcc 3.4.3 bootstraped using installed gcc 4.0:
gcc/intl/configure test using gcc 4.0 and found /usr/local/include/libintl.h
and remember this
But stage1 gcc 3.4.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
18:43 ---
Fixed in 3.4.0:
: Search converges between 2004-02-02-3.4 (#1) and 2004-03-01-3.4 (#2).
: Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446).
--
What|Removed
A "gcc -Wall -c test.c" of the following compiles cleanly while it should
generate an error as incorrect code will be produced for function calls to foo()
via bar().
int foo(void) __attribute__((regparm(3)));
int (*bar)(void) __attribute__((regparm(0))) = foo;
--
Summary: i386 regparm
--- Additional Comments From dalej at apple dot com 2005-01-31 18:27
---
Fixed by patch above.
--
What|Removed |Added
Status|ASSIGNED|RESOLV
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
18:20 ---
I think it is time to check your memory and/or hardware, this works for so many
other people.
--
What|Removed |Added
--
What|Removed |Added
Component|tree-optimization |c++
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-31
18:16 ---
Not a gcc bug so closing.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-31
18:01 ---
Subject: Bug 19650
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-31 18:00:52
Modified files:
gcc: ChangeLog fold-const.c
gcc/t
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |law at redhat dot com
|dot org |
Status|NEW
--- Additional Comments From law at redhat dot com 2005-01-31 17:30 ---
Subject: Re: [4.0 Regression] A side effect
is missed in 0 % a++.
On Mon, 2005-01-31 at 14:44 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2
--- Additional Comments From sitaram dot banda at gmail dot com 2005-01-31
17:23 ---
(In reply to comment #3)
> gcc 3.2.x was definitely not stable on opteron. As far as I remember,
> opteron support was developed by SuSE on the hammer branch and by
> redhat on top of their 3.2.x based
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-31
17:02 ---
This looks promising.
I'll do a full check later.
Thomas
--- transfer.c.orig 2005-01-31 18:03:12.0 +0100
+++ transfer.c 2005-01-31 18:04:00.0 +0100
@@ -150,6 +150,14 @@
--- Additional Comments From wanderer at rsu dot ru 2005-01-31 16:59
---
I found problem:
At FreeBSD intl.h placed in /usr/local/include
and gcc 3.4.* not search by default /usr/local/include for system headers
(I check this for system compiler gcc version 3.4.2 [FreeBSD] 20040728 and g
--- Additional Comments From pcarlini at suse dot de 2005-01-31 16:39
---
*** Bug 19725 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-01-31 16:39
---
*** This bug has been marked as a duplicate of 17005 ***
--
What|Removed |Added
Statu
--- Additional Comments From charlet at adacore dot com 2005-01-31 16:38
---
Subject: Re: gnat tools not buildable cross
> I don't think so. When you get into the libada directory,
> CC="$(CC_FOR_TARGET)"
> and all hope is lost of having the tools work in a cross configuration.
That
1. code below compiles into many instructions like "movl $0, 16(%eax)", should
have been "stosw" since all initializations are zeros. Even if one or two are
skipped in the middle still bulk stosw should be used.
2. Even when class E with external constructor uncommented this shouldn't change
since
1 - 100 of 163 matches
Mail list logo
