Hi,
the following code snippet shows that gfortran calculates
the upper bound wrong when the lower bound is not 1.
(If this a bug in libfortran, please adjust the subject.)
module gfcbug22
implicit none
contains
subroutine foo (a)
integer :: a(0:)
if (lbound (a, dim=1) /= 0 .or.
Hej !
The backend optimization in GCC for ppc750 to use floating point
instructions for struct copy causes problems in embedded applications.
This optimization is tied to the _mhard-float flag. In the OS we use
(OSE) floating point is default disabled and enabled via exception at
float
Hello
Ok, thanks. The important section of the C99 standard is Annex G (IEC
60559-compatible complex arithmetic): it even provides a reference
implementation of the division in Example2. Perhaps, you could have a
look to a public draft of the final standard, just Google a bit... ;)
But
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
09:37 ---
Subject: Bug 16681
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 09:37:37
Modified files:
gcc/cp : ChangeLog init.c
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-09
09:39 ---
fixed on mainline
2004-12-09 Nathan Sidwell [EMAIL PROTECTED]
PR c++/16681
* init.c (build_zero_init): Build a RANGE_EXPR for an array
initializer.
--
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-09
09:41 ---
sounds reasonable to me. note that gfc_offset is either a 32 or a 63 bit value
depending on offset_t.
there is a testsuite file to test this exact problem,
unopened_unit_1.f90
! PR 14565
program
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple
--
What|Removed |Added
Known to fail|3.3.4 3.4.1 4.0.0 |3.3.4 3.4.1
Known to work|2.95.4 3.2.3|2.95.4 3.2.3 4.0.0
--- Additional Comments From schwab at suse dot de 2004-12-09 10:11 ---
Created an attachment (id=7711)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7711action=view)
Reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
10:34 ---
Subject: Bug 18073
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 10:34:24
Modified files:
gcc/cp : typeck.c ChangeLog
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-09
10:39 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
10:44 ---
Subject: Bug 16681
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 10:43:57
Modified files:
gcc: ChangeLog tree-inline.c
Log
--- Additional Comments From joseph at codesourcery dot com 2004-12-09
10:57 ---
Subject: Re: (foo) accepted as char[] initializer
On Thu, 9 Dec 2004, pinskia at gcc dot gnu dot org wrote:
Fixed on the mainline:
tt.c:3: warning: array initialized from parenthesized string constant
Apparently, the default algorithm (the other one available is selectable via
flag_complex_divide_method = 1) is the naive one, which is not able to deal
correctly with large denominators. For some additional details, see:
http://gcc.gnu.org/ml/gcc-bugs/2004-12/msg00820.html
I'm attaching a
--- Additional Comments From pcarlini at suse dot de 2004-12-09 11:09
---
Created an attachment (id=7712)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7712action=view)
A trivial testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
--- Additional Comments From joseph at codesourcery dot com 2004-12-09
11:17 ---
Subject: Re: New: Naive (default) complex division
algorithm
On Thu, 9 Dec 2004, pcarlini at suse dot de wrote:
I'm attaching a trivial, pure C, testcase, showing at least inconsistency in
the
--- Additional Comments From pcarlini at suse dot de 2004-12-09 11:26
---
The Annex G example still comes with a warning that it may yield undue
overflow: it illustrates how to get the treatment of infinities expected
in that informative Annex, not how to avoid excess overflow in
--- Additional Comments From pcarlini at suse dot de 2004-12-09 11:33
---
A naive idea: would make sense swithing from flag_complex_divide_method == 0
to flag_complex_divide_method == 1 basing on -ffast-math or other, finer
grained,
floating point, switch?!?
--
What
--- Additional Comments From joseph at codesourcery dot com 2004-12-09
11:46 ---
Subject: Re: Naive (default) complex division algorithm
On Thu, 9 Dec 2004, pcarlini at suse dot de wrote:
A naive idea: would make sense swithing from flag_complex_divide_method == 0
to
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-09
12:07 ---
32 or 64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-09
12:21 ---
Fix for 3.4 branch
2004-12-09 Nathan Sidwell [EMAIL PROTECTED]
PR c++/16681
* init.c (build_zero_init): Build a RANGE_EXPR for an array
initializer.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
12:21 ---
Subject: Bug 16681
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2004-12-09 12:21:33
Modified files:
gcc/cp :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
12:33 ---
Subject: Bug 18757
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 12:33:09
Modified files:
gcc/cp : ChangeLog parser.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
12:35 ---
The reason sometimes it is hard to see if a bug is against the C++ front-end, I
always look at the title
of the window which includes the summary but not the component.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
12:38 ---
Fixed at least on the mainline.
--
What|Removed |Added
Known to work|
--- Additional Comments From giovannibajo at libero dot it 2004-12-09
12:50 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00655.html
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2004-12-09
12:51 ---
Proposed (partial) patch:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00655.html
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2004-12-09
12:59 ---
My understanding is that both the expressions are ill-formed, because you
cannot use the parentesis around the type-id in a new-array expression.
GCC 3.4 and above correctly rejects both lines. There is an
--- Additional Comments From pcarlini at suse dot de 2004-12-09 13:01
---
Thanks Joseph. I will try to come up with a patch as soon as possible, but
please be gentle while reviewing it, would be my first one for the compiler
proper ;)
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
13:08 ---
Hmm, for me it passes at -O0 and fails at -O1 and this on ppc-darwin so it is
definitely not target
related at all.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
13:14 ---
I think this is caused by the same problem as PR 18694.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-09
13:15 ---
I believe that the problem which my patch was addressing was that Kaveh's
patch was causing variables to end up in .bss which needed to be in a
special section. I'm not sure why that would be, since
--- Additional Comments From joseph at codesourcery dot com 2004-12-09
13:25 ---
Subject: Re: Naive (default) complex division algorithm
On Thu, 9 Dec 2004, pcarlini at suse dot de wrote:
Thanks Joseph. I will try to come up with a patch as soon as possible, but
There is no
--- Additional Comments From pcarlini at suse dot de 2004-12-09 13:31
---
There is no regression here, so I recommend holding off until 4.0 has
branched.
Definitely. Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
13:59 ---
Subject: Bug 16681
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED] 2004-12-09 13:59:26
Modified files:
gcc/cp :
int g (char *s, const char *format)
{
const char *f;
const char *string;
static const void *step0_jumps[] = {
do_form_integer
};
f = format;
do_form_integer:
goto end;
string = s;
end:;
return 0;
}
: Search converges between 2004-10-18-014001-trunk (#596) and
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
14:10 ---
I should say I found this while reducing PR 1.
--
What|Removed |Added
Target
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
14:13 ---
Here as reduced testcase as I could find:
typedef long unsigned int size_t;
extern void abort (void);
extern char *strcpy (char *, const char *);
extern int strcmp (const char *, const char *);
typedef
--- Additional Comments From schwab at suse dot de 2004-12-09 14:19 ---
The patch does no good on ia64, it causes the stage2 compiler to be
miscompiled.
--
What|Removed |Added
--- Additional Comments From amacleod at redhat dot com 2004-12-09 14:34
---
Im confused. I see a final form of:
f (a)
{
bb 0:
return (a -129) == 144;
}
when I compile this program with mainline. Isnt this what you claimed it should
be compiled to? or are you claiming it should
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
14:38 ---
(In reply to comment #4)
when I compile this program with mainline. Isnt this what you claimed it
should
be compiled to? or are you claiming it should be optimized to 'return 0'?
I am claiming it
Third iteration at fixing the duplicate PACKAGE warnings from boehm-gc
should be the charm. The change from the second iteration is that this
time I grab all the GC_*_THREADS definitions too.
Tom,
My first iteration did as you recently suggested and copied everything
except PACKAGE and
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
14:59 ---
Mine, I have a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From roger at eyesopen dot com 2004-12-09 14:59
---
The patch is a partial fix as there will still be a performance regression for
the code generated vs. gcc 3.3.1. The reason being that 3.3.1 generated
incorrect code for test program in this PR.
int foo(int a)
the following code ICEs with
g++-4.0-20041205 -c -O3 ice.cc
/*-- begin of ice.cc */
struct Data;
struct Wrapper {
Data* D;
};
inline void initValue(
Wrapper w,
int Data::* res
) {
for( int i = 0; i 4; i++ )
--- Additional Comments From andre dot maute at gmx dot de 2004-12-09
15:08 ---
g++-3.3.3, g++-3.4.1 and g++-3.4.3 are o.k.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18904
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
15:09 ---
Subject: Bug 16681
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2004-12-09 15:09:33
Modified files:
gcc/cp :
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
15:10 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00684.html.
--
What|Removed |Added
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-09
15:10 ---
Same fix for 3.3 branch
2004-12-09 Nathan Sidwell [EMAIL PROTECTED]
PR c++/16681
* init.c (build_zero_init): Build a RANGE_EXPR for an array
initializer.
--
What
--
Bug 18462 depends on bug 16681, which changed state.
Bug 16681 Summary: [3.3/3.4 regression] array initialization in struct
construct is a memory hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16681
What|Old Value |New Value
With gcc 4.0.0 from today (December 9, 2004), I receive the error message
error: subscripted value is neither array nor pointer
for a piece of code that looks fine and is accepted by Intel's icc. Some
relevant lines seem to be e.g.
const char* const coords = xyz;
for (int d=0; dD-1;
--- Additional Comments From schnetter at aei dot mpg dot de 2004-12-09
15:12 ---
Created an attachment (id=7713)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7713action=view)
gzipped failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18905
--
What|Removed |Added
Known to work|2.95.4 3.2.3 4.0.0 |2.95.4 3.2.3 4.0.0 3.4.4
Target Milestone|3.4.4 |3.3.6
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
15:19 ---
Confirmed, reduced to:
struct Data;
struct Wrapper {
Data* D;
};
struct Data {
int X;
void init(Wrapper);
};
void Data::init( Wrapper w ) {
int Data::* res = Data::X;
w.D = this;
for(
--- Additional Comments From schlie at comcast dot net 2004-12-09 15:23
---
Subject: Re: [3.4/4.0 Regression] ~6x+ performance
regression, constant trees not being computed.
Few thoughts:
- I believe avr's back end does know how to convert:
((char)x pow2-const) = bit-test x
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
15:25 ---
Reduced testcase:
int f1(char);
template int t
void f(void)
{
const char* const suffixes = plpv;
f1(suffixes[t]);
}
: Search converges between 2004-11-25-014001-trunk (#656) and
2004-11-25-161001-trunk
--- Additional Comments From drow at gcc dot gnu dot org 2004-12-09 15:36
---
Fred's request makes perfect sense to me.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
15:39 ---
here is the patch (for some reason I cannot send it out, stupid mail servers):
Index: tree-chrec.c
===
RCS file:
--- Additional Comments From schlie at comcast dot net 2004-12-09 15:52
---
Subject: Re: [3.4/4.0 Regression] ~6x+ performance
regression, constant trees not being computed.
Sorry, lost the fact that only a single bit needs to remain significant in
the resulting trasform:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
15:54 ---
Subject: Bug 18102
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 15:54:16
Modified files:
gcc: ChangeLog c-incpath.c
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
15:54 ---
Subject: Bug 18102
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 15:54:16
Modified files:
gcc: ChangeLog c-incpath.c
Log message:
--
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2004-11-30 00:39:17 |2004-12-09 15:54:55
date|
--- Additional Comments From gdr at integrable-solutions dot net
2004-12-09 16:03 ---
Subject: Re: Naive (default) complex division algorithm
joseph at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Additional Comments From joseph at codesourcery dot com 2004-12-09
11:46
--- Additional Comments From wolfgang dot roehrl at de dot gi-de dot com
2004-12-09 16:15 ---
Subject: Antwort: Type of 'new (T*) [n]'
Hi all,
I am responding to the Comments From giovannibajo at libero dot it
2004-12-09 12:59 (Bug report 18901):
The expression 'new (int*)[3]'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
16:17 ---
Subject: Bug 18904
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 16:17:07
Modified files:
gcc: ChangeLog tree-chrec.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
16:17 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From law at redhat dot com 2004-12-09 16:20 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 02:51 +, kazu at cs dot umass dot edu wrote:
--- Additional Comments From kazu at cs dot umass dot edu
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
16:31 ---
Subject: Bug 18895
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 16:31:23
Modified files:
libgfortran: ChangeLog Makefile.am Makefile.in
The following code:
static inline int cpuid_edx(int op)
{
int eax, ecx, edx;
__asm__(push %%ebx\n\tcpuid\n\tpop %%ebx
: =a (eax), =c (ecx), =d (edx)
: a (op));
return edx;
}
int RIGHT_CPU(void)
{
return cpuid_edx(1);
}
Compiles fine on a Fedora
--- Additional Comments From dje at gcc dot gnu dot org 2004-12-09 16:32
---
AM_MAKEFLAGS removed from libgfortran/Makefile.am
--
What|Removed |Added
Status|NEW
The attached list of Makefile.am files set AM_MAKEFLAGS. This was need to work
around a bug in GNU Make that was fixed in version 3.79. Since the GCC install
instructions say that GNU make 3.79.1 or later is required to build GCC these
workarounds are no longer needed and should be removed. See
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
16:38 ---
Not a bug, you want pushl and popl instead.
--
What|Removed |Added
--- Additional Comments From gdr at integrable-solutions dot net
2004-12-09 16:38 ---
Subject: Re: [3.3/3.4 regression] array initialization in struct construct is
a memory hog
nathan at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Same fix for 3.3 branch
| 2004-12-09 Nathan
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
16:39 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
On 9-Dec-04, at 9:51 AM, Kelley Cook wrote:
Third iteration at fixing the duplicate PACKAGE warnings from boehm-gc
should be the charm. The change from the second iteration is that
this time I grab all the GC_*_THREADS definitions too.
Tom,
My first iteration did as you recently suggested and
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18907
--- Additional Comments From nospampeeps at yahoo dot com 2004-12-09 16:44
---
(In reply to comment #1)
Look at PR 17940.
Do you have the environment variable MAKE set to gnumake -r or something
like that?
Yes, I had MAKEFLAGS='-rj 2'. Clearing the variable seems to have corrected
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
16:46 ---
You most likely did not clean it before doing a configure. This is not a gcc
bug so closing.
--
What|Removed |Added
--- Additional Comments From law at redhat dot com 2004-12-09 16:47 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 14:19 +, schwab at suse dot de wrote:
--- Additional Comments From schwab at suse dot de 2004-12-09 14:19
--- Additional Comments From orion at cora dot nwra dot com 2004-12-09
16:49 ---
Changed to:
static inline int cpuid_edx(int op)
{
int eax, ecx, edx;
__asm__(pushl %%ebx\n\tcpuid\n\tpopl %%ebx
: =a (eax), =c (ecx), =d (edx)
: a (op));
return
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
16:51 ---
Still not a gcc bug, I cannot be as it is complaining about the inline asm and
not what gcc produces.
--
What|Removed |Added
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 16:58
---
With my old patch (conservative-dom), stmt.c was miscompiled on my machine.
stage2/cc1 crashes on compiling crtstuff.c.
Replacing stmt.o with stage1/stmt.o worked for me.
--
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 16:59
---
Jeff,
I agree with your comment #26.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- Additional Comments From schwab at suse dot de 2004-12-09 17:03 ---
I have identified this patch as the trigger:
2004-10-25 Kazu Hirata [EMAIL PROTECTED]
* cfg.c (unchecked_make_edge, redirect_edge_succ,
redirect_edge_pred): Use VEC_safe_push instead of
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
17:33 ---
Subject: Bug 17025
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-09 17:33:45
Modified files:
gcc: ChangeLog
gcc/config/i386:
--- Additional Comments From law at redhat dot com 2004-12-09 17:38 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 16:58 +, kazu at cs dot umass dot edu wrote:
--- Additional Comments From kazu at cs dot umass dot edu
GNU C version 4.0.0 20041209 (experimental)
_Bool f1(const _Bool *p) { return *p 1; }
_Bool f2(const _Bool *p) { return *p + 0; }
_Bool f3(_Bool *p) { *p ^= 1; }
_Bool f4(_Bool *p) { *p = ~*p; }
yields
f1: ldbuv0,0(a0)
and v0,0x1,v0
ret
f2: ldbuv0,0(a0
[pluto]-[~/rpm/tmp/gcc-4.0.0-root-pluto] # find -type f -name '*gij*'
./usr/share/man/man1/gij.1.gz
./usr/bin/gij
[pluto]-[~/rpm/tmp/gcc-4.0.0-root-pluto] # ldd usr/bin/gij
/lib/libsafe.so (0xb7fe7000)
linux-gate.so.1 = (0xe000)
libgij.so.0 = not found
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
17:42 ---
Subject: Bug 17025
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2004-12-09 17:42:41
Modified files:
gcc:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
17:45 ---
Confirmed here is what we get on ppc:
_f1:
lwz r3,0(r3)
rlwinm r3,r3,0,31,31 -- not useful
blr
.align 2
.globl _f2
_f2:
lwz r0,0(r3)
addic r2,r0,-1
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
17:47 ---
How did you configure gcc?
This works for me and many other people.
Even libgcj is not found also, this looks like a something is wrong with your
build.
--
What|Removed
--- Additional Comments From brian dot morey at atk dot com 2004-12-09
17:54 ---
I am having this same issue with my code. It's too large to commit but I will
try and make a smaller test case out of it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
--- Additional Comments From giovannibajo at libero dot it 2004-12-09
18:01 ---
Reconfirmed with today's mainline. This bug has about 10 dups...
--
What|Removed |Added
--- Additional Comments From pluto at pld-linux dot org 2004-12-09 18:14
---
(In reply to comment #1)
How did you configure gcc?
This works for me and many other people.
# gcj -v
Reading specs from /usr/lib/gcc/pentium3-pld-linux/4.0.0/specs
Reading specs from
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
18:18 ---
(In reply to comment #2)
(In reply to comment #1)
How did you configure gcc?
This works for me and many other people.
Even libgcj is not found also, this looks like a something is wrong with
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-09
18:19 ---
Subject: Bug 17025
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2004-12-09 18:19:09
Modified files:
gcc:
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-09 18:21
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
What|Removed |Added
CC|rth at gcc dot gnu dot org |
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Additional Comments From pluto at pld-linux dot org 2004-12-09 18:44
---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
How did you configure gcc?
This works for me and many other people.
Even libgcj is not found also, this looks
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
18:47 ---
Again try to compile without using the rpm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18909
1 - 100 of 169 matches
Mail list logo
